Re: Easy to get rid of the lawyers
Maybe not enough thought was given to the license in the first place
On the contrary - this is exactly the situation that was desired.
This way, no-one can "take over" the kernel and turn it proprietary.
5404 posts • joined 7 Dec 2007
Maybe not enough thought was given to the license in the first place
On the contrary - this is exactly the situation that was desired.
This way, no-one can "take over" the kernel and turn it proprietary.
what idiots are making out of bundle calls? I bet there's not a single punter here who makes even a dent in their allowance.
Well, as I don't have an allowance, I guess I'm that idiot.
I was pissed off at my service going up to 15p/min until I read this article...
It's would be brilliant! No... hang on. Not "brilliant" but that other word...
That's also its weakness because it makes them delicate, allowing them to fail in obscure ways that results in a cascade where the reported point of failure isn't really the point where it started to go wrong
That's just nonsense. Explicit scripting is inspectable; the point of failure is trivially found.
Plus SysV doesn't use dependency triggering but delays.
Again, not true; the only time a script will delay is if there is good reason to do so - which a systemd initialisation will also need to do. The only difference in terms of how te two ytems are supposed to work is that systemd is asynchronous whereas SysV is synchronous. That makes SysV more robust and more easily debugged, and it makes systemd faster.
And if that had been the extent of what systemd had done, there wouldn't be this recurring argument. But it isn't; most of us couldn't really care whether the start system is sync or async, what we care about is that far too much code is getting subsumed into systemd. That smacks of very poor design.
That's because you're not working in the consumer sphere, where configurations aren't so hard and fast
Yes I am. I was supporting GNU/Linux desktops before RH decided that there was no business there. Whilst I do fewer now than at my peak, I'll wager I still support far more end-users than you do.
Configurations might not be "hard and fast" - there is significant variation between each site I attend - but that has not been simplified by systemd in the slightest; the contrary is actually true, since SysV is far more discoverable, since it supports tab-completion properly.
Not so easy when your monitor may be hooked up to a USB adapter and manufacturers aren't so forthcoming.
If you've got a reasonable river, that just works. If you haven't got a driver, it doesn't. Replacing SysV with systemd is entirely orthogonal to that situation; if it work with the latter, it will work with the former,.
Why do you think Valve has such a hard time getting game developers to code for Linux despite having such a strong distribution system in Steam?
I don't know. I don't follow Valve's affairs. But I can guarantee you that a lack of systemd has nothing to do with it, although I could believe that systemd's pervasion throughout the assorted subsytems of the OS might put some off.
You get the same problem the other way. If you divide every little thing, you end up with a chain with a bunch of weak links that aren't very obvious maintained by people who may not be there anymore and you may not be in a position to go it alone.
No you don't - because you can inspect each and every link in the chain with ease. It takes very little skill to add instrumentation to a SysV script that will tell you *exactly* what it's trying to do. The same cannot be said for systemd; you can only turn on debugging and hope that it tells you what you want.
But at least you know who to complain to when things go wrong.
Many of us have tried complaining to Poettering over the years when things go wrong. He's not renowned for taking any notice.
#! /bin/bash to
#! /bin/bash -x in line 1 is often a good start, an really not that difficult to do...
At least if it's systemd you know where to look: systemd.
And, as systemd grows ever more bloated, that becomes less and less useful. Pointing at a box and saying "the problem is somewhere in that computer" tells you nothing; only by dissecting the problem can you eliminate it. If you can't divide the monolith wherein lies the issue, there's a limit to what you can do about it.
EVERY SINGLE COMPONENT works exactly to spec, yet when you put them together, then things go wrong.
Even if that situation were to arise - and it's hypothetical, not real - systemd doesn't help you one little bit. You've still got a complex set of components, you've merely obfuscated the startup mechanism.
If that were true, why are there constant complaints about things breaking?
There aren't. There are claims of such from people who would replace SysV. I've a zero breakage on any machine I own or control. And I don't know anyone who has.
The one complaint you *can* throw against SysV is that it is quite slow. Yes, it is. It's a synchronous start. That really doesn't bother me in the slightest.
What I see is a bunch of bodges on top of bodges
Well, everyone is entitled to an opinion. What I see is a tried-and-tested system that works effectively and doesn't need to subsume every other system in the OS.
which is why things keep breaking.
Says you. Those of us who have done this for a living for many years don't see things breaking unless someone has been dibbling with them - as is the case for NetworkManager, PulseAudio, and systemd. I'll find the common cause there one day...
PCI and PCI Express are not fixed buses. You have to POLL them to learn what they house. Universal Serial Bus has to be polled.
So what? We've been doing that for *years*.
systemd does not add new functionality in this area - it just does the same old stuff in a different way. This is why some of us are pushing back - what was there wasn't fundamentally broken. It didn't need reinventing, and it didn't need replacing with an opaque blob that will be much harder to troubleshoot when something goes wrong.
I've never had a problem using the old System V method which was decades-stable
SysV scripts can be a little intimidating at first; you'll notice that the systemd-proponents seem to like to make a fuss about how many lines they are. But that length is a strength, IMO, not a weakness; you have the operation of the script laid out explicitly for your examination, rather than hidden within an executable. SysV scripts are very debuggable, and trivially modified if you want *your* box to do something different to what the package maintainer wanted.
Now I daresay that much or all of what I want to do is possible within systemd - but that involves learning another control system. I already know Bourne-shell scripting - I think it's pretty much certain that any successful *nix admin will - so all we're really doing here is taking an easily-readable, debuggable script written in a language I understand well and replacing it with a configuration file for an executable I don't know and can't readily inspect. That's obfuscation.
I've also never seen network adaptors 'reverse' (and I run multi-home machines, so there)
I have when you change the physical hardware. I'm not sure I really know how to identify a particular card except by its PCI position (fragile) or its MAC address (somewhat more resilient).
The former could probably be done with udev or similar (I've never done it, and never expect to, since it's a horrible way of doing things). The latter is trivial. I can't actually think of a third way...
on FBSD I can configure the system to take specific actions when a USB device of a particular type is plugged in. I think you can do the same on a basic Linux system as well, particularly one without systemd on it.
Yes. Such things were a problem when I first started using Linux (about 17 years ago), but were fixed a very long time back. It's ancient history...
How do you keep a rogue process from making a fake tag when the process can match any tagging the logging system uses?
Even if you can - and your newline argument is bogus - all you're doing is cluttering the logfile; you're not removing any genuine logging, just adding a bit of noise.
And if the log you're trying to dibble with has a separate file (e.g. maillog), you don't get to write to that file anyway. Putting sendmail messages into /var/log/messages will ring every alarm bell there is...
The fake process newlines its log
Newlines are stripped out by syslog...
How do you know which process REALLY said what if all you have to work with is ASCII
syslog tells you - both process name and PID. So your mythical pwned process could put whatever it likes on the line after that - but only the truly clueless would not notice that the very beginning of each line tells you exactly where the message came form.
Oh, yes, I could set up systemd to not restart that process
And if you did want it to restart, inittab has had the "respawn" tag for as long as I can remember...
How would you feel if another country's military arrived and destroyed our government?
The last time that was a serious proposition was in the early 1940s.
The SIS established the "Home Defence Scheme", and other parts of government established the "Auxiliary Units". Both of these groups were intended to use "irregular warfare" methods against an invader.
These days, we'd call that terrorism. Back then, we considered it valour.
We are starting to mix things up here, but the client-side salting is intended to avoid/minimise replay attacks. The goal here is that the server should not have knowledge of the actual password.
I understand what you're trying to do - I'm pointing out that it is ineffective.
If you apply salt at the client end, all you've done is add a few characters to the password used; the hash is just a hash, and susceptible to rainbow table attack. You also need to get the salt to the browser each time you log in - either by transmission from the server or by storing it locally. This is all a bad idea.
This is orthogonal to an attack (including self-inflicted) on the server end.
But the attack on the server is much more likely to succeed by your method; you only need a collision or a rainbow match. By using salting correctly, you would obviate that problem, but with the method you describe, all that is required is for a captured hash to be reproducible. That's a very much simpler problem if you don't salt correctly.
And - it's just occurred to me - if the client side is doing the hashing, then all the server is doing is a text comparison. So if an attacker has captured the hash - either off the wire or from a server compromise - he doesn't actually need to do any attacks, since that is the set of characters that will get him in. That makes a server-side compromise very dodgy indeed.
True, that's why you use a session based salt. The next session/login, the salt will be different and a hash replay attack will thus fail
That can only work if you're storing the password in cleartext on the server; That's a very bad idea.
It does add security, actually, as the password never hits the wire and so it can't be leaked, even accidentally.
I beg to differ; if the salt+hash occurs in the browser, then the salt becomes irrelevant. What is sent back is a simple hash, which is therefore susceptible to collision and rainbow table attack just as any other unsalted hash.
That's the way all the APIs that I have designed work, ever since making a rookie mistake many years ago, when user passwords accidentally ended up in the database logs.
Sure, but compromising your wire protocol to avoid schoolboy coding errors on the server is probably a mistake.
They could not have had steam catapults fitted, because there is no steam plant to generate steam
I wonder whether that is set in stone...
There's quite a bit of electricity available on these ships - it shouldn't be beyond the whit of man to put an oversized kettle on board to generate steam.
Caution: very rough calculations ahead...
The large steam catapults described here generate a thrust of 36,000Kg over a length of 94m - that's some 34MJ. That's the energy expended per launch.
This page is about energy storage in compressed air - I've assumed a similar compressibility for steam. It reckons 1m³ of compressed air at 70bar stores approximately 30MJ - that's pretty much the same figure as an aircraft cat launch. A dozen such cylinders essentially gets you one launch for each of the aircraft we're actually planning to have without recharging...
Of course, these boats have been designed by BAe Systems, so we're going to be looking at >£5B per ship just to do the above calculation...
Something we might use is better value than something we'll never use.
That depends on how you define "use"...
If a deterrent weapon is ever fired, it has failed. If its purpose is to deter, its use is to sit ready without every being fired.
This makes the Vulcan either one of the most successful aircraft ever built, or possibly one of the least successful. I'm going for the former, as I'm rather glad not to see its payload being delivered in anger.
 Yes, I know it dropped conventional bombs in the Falklands. But it was built as a nuclear bomber.
It does mean that this is useless for hard real-time applications. Branch execution time is now impossible to predict.
I wouldn't go that far; worst-case branch time is still predictable, so it's still possible to do hard real-time.
Whether it's worth doing so is another matter...
Then why did they bother to take the tickets?
then before long it will be security services killed a suspected terrorist who as it turns out had no links to terrorism whatsoever - and people will say "well... if it keeps me safe, I suppose we'll just have to live with the possibility that anyone could be killed for being a suspected terrorist - even if they aren't"
This is, of course, most worrying if you happen to be a Brazilian electrician.
I am guessing the beer he consumed with his food was enough vegetation to keep him regular.
For most beers, it's actually the isinglass that has that effect on the body. And isinglass is not vegetation.
I tend to favour vegan beers - not because I'm vegan, but just because they tend to taste better :-)
People who are veggie on animal welfare grounds can make an argument that a fish lives a natural life up until the moment its caught
Farmed fish is no more and no less "natural" than farmed pig or cow...
at the (and this is one of those coincidences that Google may end up regretting) expense of being byte code compatible with Java
Dalvik is not byte-code compatible with Java. It merely has similar APIs.
Would the OpenJDK API not be essentially identical to that of Oracle's JDK?
If the API is the same (or near enough) could Oracle reasonably claim infringement by Google without also claiming infringement by everyone else using OpenJDK?
See how daft the whole thing is?
Google's use of Harmony to create Android was endorsed by Sun. How much has that helped?
The difference is that OpenJDK is GPLv2 (and has the ClassPath exception); that very explicitly prohibits field-of-use restrictions, so attempting to make a case out of tat would mean no-one could use OpenJDK. That's not going to fly...
Thought you weren't allowed to fly drones near airports.
You aren't. They are.
At AAIB the other week, they were telling us about their drones - DJI units, but modified to be allowed to fly within ATZs.
cue an update to the software ti add a "if (! load_on_undercarriage)" to the code that retracted the under carriage
Relying on that is specifically warned against...
Some pilots were in the habit of pre-selecting gear up, then taking off. As the aircraft leaves the ground, the wheels are retracted of their own accord. And it all looks very cool.
And then you hit a bump just before takeoff, the load goes light, and the wheels are retracted long before rotate speed...
and as of this writing (2015) it handles about 400K to 500K HTTP requests per day
500K requests per day is only about 6 per second.
Perhaps the Census could have run two bare metal powerful servers to get a similar result, and saved >$8 Million?
I think they'd need a bit more than that. But I still don't know how to spend that much money on the job without flagrant gouging...
The other thing to remember is that 260 submissions per second doesn't mean 260 DB transactions per second; far too many shitey websites bury everything in the database, so a single page render can mean >50 transactions. That sort of coding hammers the DB.
the V-force, which required the airbases still be in tact to launch.
The V-force might have required some airbases to be functional, but it was pretty resilient in terms of which ones.
If you look at the undercarriage on a Vulcan, for example, you will see a rather large number of wheels. A more conventional design would have been lighter, leading to a better aircraft - but doing it the way they did meant that it could land on a wider variety of surfaces, so the destruction of the home base would not necessarily put the aircraft out of commission.
If someone knows that the software they are writing is going to be OSS, I would hope they spend a little more time actually make it work correctly and be properly documented
Code is like underwear; if you're going to display it to other people, you really want it to be clean...
Not quite a definitive solution, but just enable strict SPF / DKIM and mark all external mail by amending its subject, or something like that.
That requires the domain owner not to be a dork; many of them fail badly at that hurdle.
I went through a phase a while back where I was seeing loads of domains with "+all" at the end of their SPF records. I cannot see a single instance where that can be anything but harmful, so my SPF milter now treats "+all" as if it were "-all". That helps...
Please review the meaning of the word "geostationary" and get back to me.
Everyone except you knows the meaning of the word "geostationary". For your edification, I shall give you a simple definition: it means the orbiting object has the same angular velocity as the Earth. This only means it is moving at the same speed if either the distance above the Earth is zero (i.e. it is on the ground) or of the angular velocity is zero (i.e. the Earth is not spinning). Neither of these situations relates in any way to this situation.
So here - I wasn't going to do this, but you appear to need a worked example. Here are my initial data:-
Your super-ladder sits with its base on the equator, and (initially) points directly upwards).
The circumference of the Earth is given by 2*pi*r = 40,000 km, near enough. It makes one full rotation per day, meaning its speed is 40,000 km/day or nearly 1700km/h. This is the speed at the bottom of your ladder.
Now let's look at the top of your ladder. The distance from the centre of rotation (the core of the Earth) is 35,786 + 6378 = 42184km. The distance the top travels in one complete rotation is given by 2*pi*r = 265,000km approx.
Now if your assertion about the speed being the same at the top as at the bottom, then the distance travelled in a day would be the same at the top as at the bottom. Thus the top of your ladder would travel a mere 40,000km a day - which is rather less than a sixth of the distance it needs to travel to make a complete rotation. It falls over very quickly; it is *not* geostationary.
Conversely, if it were geostationary, it would travel the entire 265,000 km in a day. This would leave the top of the ladder above the bottom, as required - but the speed at the top is now our 11,000 km/h as declared in the NASA figures, and is very much not the same as the speed at the bottom, as you have asserted.
So tell us - which of these do you prefer? That your "geostationary" ladder is no such thing, or that your assertion is plain wrong? Either makes you look decidedly foolish.
Your position is untenable. You have chosen to ignore the fact that NASA's factsheet declares you to be completely wrong, I notice. Now I've had to hand-hold you through basic arithmetic to prove that your theory cannot hold water. Please stop bullshitting and read up on the geometry of circles - it's really very easy and would mean you don't make such monumental cock-ups in future.
FWIW, I do understand your points. It's just that my point is still perfectly valid.
No, it isn't. Your point is wrong. Your continued assertion that it has any value demonstrated that you have no understanding whatsoever of the arguments presented here. Your continued avoidance of the discrepancy between your claim and the data offered by an agency that has put satellites into orbit speaks volumes.
Thus while a glider pilot has an obligation to keep a lookout and get out of the way if he has to most glider pilots will prefer to stay in the gaggle or thermal
Of course - I've spent my time in thermals, and I understand the desire. And most power pilots would be happy for you to do that. What I was reacting to was the claim that "if I'm circling in a thermal I actually have a right to keep circling and YOU are obligated to avoid me". That bit just isn't true...
(Pilot was tracked down and received a VERY stern talking to from police in this case
It doesn't always work out like that. An acquaintance of mine had an airprox with a glider some while back - he just hadn't seen him. The glider pilot filed the airprox, and in his statement, belaboured how clear the vis was, and how he'd been able to see to power plane coming for miles. They threw the book at him - although the power pilot had failed to see the glider, the glider pilot had deliberately flown a course that led to the airprox even though he know there was a powered plane there.
Vic offered that geostationary orbit requires "11,100 kmh".
NASA offered that geostationary orbit requires "11,100 kmh". You say they're wrong. Can you not see why this is a poor starting position?
Or use a 'really tall ladder' (space elevator), which is not *yet* practical. But orbital mechanics theory says is possible.
No it doesn't! You're mistaking angular velocity for orbital velocity. There is a radius multiplication you've missed out, which is why you're getting the wrong answer time after time after time.
If you were to read up on this, rather than simply reposting your ignorance, you might actually learn something.
The same basic equations still apply and so the space end of the space elevator has to have a higher orbital velocity relative to the earths CoG than the earth attached end.
Watch yourself - arguing against our very own Orbital Mechanics Genius will attract downvotes for you like it did for me...
Why the Sun? Why not the Moon?
Because the Sun can be considered a fairly stable reference point for the system - a datum line between Earth and Sun moves about 1 per day. You can do it with the Moon if you prefer, but there's a whole lot more mathematics in that, and you seem to be having difficulty with basic multiplication at the moment.
Thinking - you're doing it wrong.
One of us is - and you're yet to explain why your theory disagrees with NASA's. You might want to start there first.
So how does God tell the difference between the bowling ball that reached geostationary orbit in the traditional high speed manner, and the other bowling ball that was slowly carried straight up and gently placed into geostationary orbit, just beside the first?
There is no need to tell any difference between the two, since they have both been accelerated to the same velocity.
Two bowling balls in precisely the same state
Yes - precisely the same state. Both have been accelerated to orbital velocity. They are both going sideways at quite a lick.
Orbit achieved without moving quickly at any point. Energy installed by slow lifting, not speed.
No. Completely, horrifically, abjectly incorrect.
Can you really not cite the formula for the circumference of a circle? That's the length of the orbital path. If the ball were doing the same speed as the ground beneath it, it would take far more time to complete that orbit than would the ground beneath - meaning it would not be geosynchronous, and the top of your ladder would be falling behind. This means the ladder falls over, along with your theory.
If, however, both the top and bottom of your ladder have the same angular velocity - which is a requirement for it to be upright, then they cannot have the same speed for any length of ladder >0. The top of your ladder is going faster than the bottom, or else it falls over. Similarly, a ball lifted up the ladder will be accelerated by that ladder too match the speed of each bit of the ladder during the ascent.
This is basic geometry. It amazes me that you continue to argue something which, as I have pointed out, NASA tells you is wrong. Now it's always possible that you are right and both NASA and I are wrong - so let's see some evidence. How many satellites have you put into stable otbit, about his planet or any other?
Any thinking person can understand the above.
Yes. It troubles me that you do not.
Relative to the Earth (why do I even need to type that?)
Because it's the irrelevance that makes you think you have a point. you don't. Try thinking relative to something else - e.g. the sun. You will see that *all* these objects are moving.
Both are zero mph relative to the Earth's surface,and the Earth itself.
Had you thought about taking your theory to any of the major space agencies? Because they all expend an awful lot of energy making spacecraft go sideways, and according to you, that's unnecessary. You have just revolutionised orbital mechanics. Or maybe you're just wrong. Hmmm.... let me think about that one.
NASA's opinion on the subject reckons that geostationary orbit requires a speed of 11,100 KM.hour. Perhaps you'd like to tell us all why they're wrong.
Since it's quite trivial, it indicates a gap in basic understanding on your part, or a monumental communications failure between us.
It's very simple to grasp, and I cannot help but be astounded at your failure so to do. But your evaluation of the possible causes omits one very important one: that you're utterly and completely wrong. And that being the correct assessment, you're not going to get any further on this until you go and read some factual material, rather than just making it up as you go along. You assertion that a geostationary object is not travelling sideways at great velocity is as wrong as asserting that a car doing 70mph is stationary, because there's another car alongside also doing 70mph; you appear to have forgotten that the Earth is spinning.
You're very confused about the altitude of geostationary orbit.
You're very confused about orbital velocity.
You also missed the key point about 'bowling balls' not having memory.
You missed the key point about the second ball being accelerated sideways during its passage up the ladder. You know the angular velocity of a geostationary object - that's the bit that stays the same for the ball you're carrying up the ladder. But the velocity of any object of constant orbital velocity will necessarily increase as the radius of the orbit increases. This is basic geometry...
This whole thing was a counter example rebuttal
It really wasn't...
Perhaps you could read up on space elevator theory
Perhaps you should consider what happens when the velocity of the top of the elevator is the same as the velocity of the bottom, despite having a much larger path to traverse each rotation.
ALL planes have a responsibility to maintain lookoit and traffic separation
This is entirely true.
And whether you like it or not, if I'm circling in a thermal I actually have a right to keep circling and YOU are obligated to avoid me
And this is not - it contradicts the earlier statement.
Even if you're in a thermal, both aircraft have a responsibility to avoid conflict. If that means you have to leave the thermal because you've seen the other pilot and he hasn't seen you - that's how aviation law works. You do not have a god-given right to stay in the thermal while everyone else gets out of your way, even if power pilots will try to afford you that luxury.
I doubt that would work seeing that no two devices in our house show the stream in sync.
DTT devices should do - there is timing information in the transport stream to synchronise playout of both audio and video against the clock reference. This is how lipsync works.
That said, I've fixed the ST-derived tree at all but one device manufacturer independently. It wouldn't surprise me to find out that other reference trees have similarly glaring bugs...
 Through the most unbelievable piece of cut-and-paste fuckwittery, the audio and video streams were both synced accurately to the 27MHz reference oscillator, but not to each other or to the reference timestamps. So you could watch a wall of TVs in Dixons, each one playing out audio and video at different times :-)
In the 12 months I had it I had total hydraulic loss 3 times
I drove XMs for quite a few years. I only had one total failure.
The emergency brake was barely adequate, but it would have been so much worse if it had been a handbrake...
 I snapped the belt that drives the hydraulic punp. In a well-maintained XM, this should cause gradual loss of pressure, with quite some time before total failure. But my XMs were never in that category...
 I was doing somewhere in the region of 90mph, just south of J9 on the M3. There was no way I was going to get through the traffic and onto the junction, so I had to keep it rolling for a couple of miles and pull up after the sliproad. That was interesting...
"Can Microsoft really put GPL applications in their 'windows store' without breaking the GPL ?"
I don't see why not
Then you might want to read the licence, as it gives the answer most explicitly.
They aren't offering as part of their own product. It's just a transfer of data
That does not matter one bit. If they are redistributing the code that is permissible only under the terms of the licence - which, for a commercial redistribution as this would be, requires either the transfer of source with the binary, or else a binding promise to supply that source on demand.
"We are terrible at teaching people how to make things secure. We're not paying enough attention to what they need."
This is total cobblers - we're very good at teaching people how to make things secure. The trouble is that the people who take the decision to ship code are actively resistant to such advice, seeing it merely as "negativity". This will not change until the penalty for overseeing such a project is personally appreciable to those decision-takers...
Given the current quality, the only way that plane could act as a deterrent was if you stuck Kamikaze pilots in them
Not so. The F-35 is a very effective deterrent.
The threat goes along the lines of "do as we say, or we put you on the customer list"
If they're using MD5, then they're unlikely to have salted the hash. In that case the passwords can be cracked using rainbow tables, so deriving the password from the hash is easy
Aside from your first assumption often being wrong, an attack on MD5 doesn't usually reveal the original password.
It relies on MD5 collision, so it reveals a password that generates the same hash. It is unlikely that this is the actual password, although it will be sufficient for authentication in this situation.