The waste from coal burning isn't particularly safe, whether we are talking the solid parts or the gas. We have a bit more experience in handling large quantities of it, of course.
Also in 1911 came the development of automatic helm control for ships. The technology ended up faster, more accurate, and more reliable than a trained, experienced career helmsman. Guess what the major complaint was? Yeah...it was "unsafe"
That is unsafe though. Way too many ship pilots are drunk and/or asleep, and if the ships didn't automatically stay on course, we would likely spot the problem BEFORE they manage to ram into a bridge again.
Of course the real solution here is to install dead man's switches and alcometers on board all cargo ships, or make automatic helm control include a bit of collision avoidance. Or just keelhaul those idiots.
The idea of training a flight attendant to perform a landing in the case of a pilot's death means that you would be trusting a minimally trained "pilot" to land a large jet with several hundred people aboard about once per year. That's absolute insanity. That's not cost cutting. It's homicide.
You're assuming a manual landing. It should be reasonably easy to train a flight attendant to program an autopilot to land.
No you're just gambling that if the co-pilot gets sick, the normal automatic flight+landing proceeds without problems. I don't think it's infeasible to get 99% of flights fully automatic. Right now I don't think any passenger planes can take off automatically, but take-offs shouldn't particularly difficult to automate.
Any car that can't do 90MPH safely on an otherwise empty road should be taken off the roads immediately. Do regular car inspections and that problem all but disappears.
Also, require tires to be rated for the maximum speed the car can do. That encourages electronic speed limiters, as above 250km/h tires are fairly expensive.
The parent is not a troll, it is spot on. The problem is that the database backend and the language frontend are tied together. To invent a new query language you need to invent a database backend to go with it, and you can't try out a new query language on an existing database deployment. Similarly, any innovations in the database backend are hampered by the limited syntax of SQL. If you can't make a small extensions to SQL to get it working, then you can forget about implementing it at all. This pretty much means game over for any database innovations.
Even Relational Algebra is infinitely easier to understand than the pseudo-English mess that is SQL. Much like even Haskell is easier to read than COBOL.
The 60 thing is easy to handle. The problem is that right now you have
$ LC_ALL=en_US.UTF-8 date -u -d '@1300000000' Sun Mar 13 07:06:40 UTC 2011
In 6 months time this same command could return a different output, perhaps 07:06:39 or 07:06:41. And the result on different computers depends on whether the zone files have been updated or not.
Right, so we should propose to standardize the Internet on TAI then. As long as we can relegate UTC to something only astronomers care about like sidereal years, I'm happy.
You are wrong. Leap days fix the fact that the year isn't an integral number of days. Leap seconds fix the fact that the day isn't an integral number of seconds. Neither helps the other.
It seems far more sensible to make a small adjustment reasonably regularly than a large adjustment every 100 years as, for the general population at least, the adjustment will pass without being noticed.
Except we're talking a not-too-large adjustment every 1000 years, possibly even every 10000 years.
You can't get leap seconds right, in general. They shift future events unpredictably, and even getting updates on to all computers within the couple of months warning of a leap second is a challenge.
From a commercial viability view point, Solaris has pretty much been dead since the tech crunch. It took a while for Sun's money to run out, but now it has, and there is no way Oracle can bring Solaris back to profitability without almost completely killing development.
Itanium killed Irix and HP/UX, although the latter is still pretending to be alive.
There's basically Windows, traditional Unix with X11 (with only Linux, *BSD and AIX left), and Unix + different UI (Mac OS X). Plus some embedded systems and some mainframe-like systems, but Unix is eating both.
We aren't exactly witnessing a Cambrian explosion.
If you can shoot 120 km straight up you can shoot less than twice as far if you pick a 45 degree angle. 240km rockets are nothing special for most nations who care about such things. If you have a hardened payload and safety isn't a major concern, solid-fuelled rockets are probably easier.
I was under the impression that very few Windows applications were statically compiled... so why can't this just be updated in whatever shared object it uses again?
Because to avoid dependency hell and to compensate for the lack of package management, Windows applications come with private copies of the DLL's they need. If a flaw hits a common library like a JPEG parser you have to go through the file system looking for vulnerable versions and hope all the versions you have installed have fixes available. Or just wait till each application vendor gets around to issuing a patch for their particular application.
My gripe is how SELinux is expected to be able to confine malicious code which is already executing inside the kernel.
Ah right. No one should sanely expect this. I just got stuck on your explanation about locks; moving locks around wouldn't help, because the malicious code does not need to respect any locks.
It works like this: The malicious code invokes the syscall passing a structure, e.g. an inode but at the same time the malicious code starts a second thread which after a measured period (clockcycles) modifies the very same structure. By crafting this carefully the attacker can hit the "weak spot" between the security checks and the actual operation. It doesn't work every time due to obvious nondeterminism, but even a 30% hit rate will be exceptionally good in a mass attack.
If this was true, it would be a massive security hole rendering SELinux useless. SELinux isn't just a "last line of defense" thing which has a chance of reducing the impact of other vulnerabilities, it is an implementation of a Mandatory Access Control system. If you can come up with a generic way for a confined root user to bypass SELinux, by all mean publish! If it is as easy as you say it is, you should be able to come up with a demonstration in no time. Even a 1 in a million hit rate would be fairly easy to demonstrate and make you moderately famous in the security community.
The hosts file blocks whichever HOST NAMES you put in (and give an unreachable address). This works equally well with ipv6 and ipv4, and the number of host names doesn't magically increase with ipv6.
Which MLC drives are you using? I have so far had extremely positive experience with SLC drives for the enterprise and Intel MLC for laptops. So positive in fact that I'm tempted to try Intel MLC for the enterprise too.
Slashdot Mirror
Yes, the safety of its waste.
The waste from coal burning isn't particularly safe, whether we are talking the solid parts or the gas. We have a bit more experience in handling large quantities of it, of course.
Also in 1911 came the development of automatic helm control for ships. The technology ended up faster, more accurate, and more reliable than a trained, experienced career helmsman. Guess what the major complaint was? Yeah...it was "unsafe"
That is unsafe though. Way too many ship pilots are drunk and/or asleep, and if the ships didn't automatically stay on course, we would likely spot the problem BEFORE they manage to ram into a bridge again.
Of course the real solution here is to install dead man's switches and alcometers on board all cargo ships, or make automatic helm control include a bit of collision avoidance. Or just keelhaul those idiots.
The idea of training a flight attendant to perform a landing in the case of a pilot's death means that you would be trusting a minimally trained "pilot" to land a large jet with several hundred people aboard about once per year. That's absolute insanity. That's not cost cutting. It's homicide.
You're assuming a manual landing. It should be reasonably easy to train a flight attendant to program an autopilot to land.
No you're just gambling that if the co-pilot gets sick, the normal automatic flight+landing proceeds without problems. I don't think it's infeasible to get 99% of flights fully automatic. Right now I don't think any passenger planes can take off automatically, but take-offs shouldn't particularly difficult to automate.
I'm impressed that they can do Full-HD on a screen with a resolution of 1024x600.
Any car that can't do 90MPH safely on an otherwise empty road should be taken off the roads immediately. Do regular car inspections and that problem all but disappears.
Also, require tires to be rated for the maximum speed the car can do. That encourages electronic speed limiters, as above 250km/h tires are fairly expensive.
The parent is not a troll, it is spot on. The problem is that the database backend and the language frontend are tied together. To invent a new query language you need to invent a database backend to go with it, and you can't try out a new query language on an existing database deployment. Similarly, any innovations in the database backend are hampered by the limited syntax of SQL. If you can't make a small extensions to SQL to get it working, then you can forget about implementing it at all. This pretty much means game over for any database innovations.
Even Relational Algebra is infinitely easier to understand than the pseudo-English mess that is SQL. Much like even Haskell is easier to read than COBOL.
That's clever! Make the computer sufficiently slow that the malware doesn't find it worth bothering.
I hadn't though of that. I guess I'll have to stop complaining about Norton now.
No amount of malware can ever drain as much performance as Norton Antivirus.
LOL: OK, so if we stopped having leap seconds that would never have any bearing on leap days then.
Thanks for clearing that up.
Correct. I'm not sure why you had the LOL bit, unless you're laughing at yourself.
The 60 thing is easy to handle. The problem is that right now you have
$ LC_ALL=en_US.UTF-8 date -u -d '@1300000000'
Sun Mar 13 07:06:40 UTC 2011
In 6 months time this same command could return a different output, perhaps 07:06:39 or 07:06:41. And the result on different computers depends on whether the zone files have been updated or not.
Right, so we should propose to standardize the Internet on TAI then. As long as we can relegate UTC to something only astronomers care about like sidereal years, I'm happy.
You are wrong. Leap days fix the fact that the year isn't an integral number of days. Leap seconds fix the fact that the day isn't an integral number of seconds. Neither helps the other.
It seems far more sensible to make a small adjustment reasonably regularly than a large adjustment every 100 years as, for the general population at least, the adjustment will pass without being noticed.
Except we're talking a not-too-large adjustment every 1000 years, possibly even every 10000 years.
You can't get leap seconds right, in general. They shift future events unpredictably, and even getting updates on to all computers within the couple of months warning of a leap second is a challenge.
From a commercial viability view point, Solaris has pretty much been dead since the tech crunch. It took a while for Sun's money to run out, but now it has, and there is no way Oracle can bring Solaris back to profitability without almost completely killing development.
Itanium killed Irix and HP/UX, although the latter is still pretending to be alive.
And clumping all "Linux" into one (from Ubuntu to Red Hat's Enterprise) is a bit of over-generalization.
I really don't think it's an over-generalization. E.g. Sun OS vs. Solaris was a MUCH larger difference than whether the package manager is apt or yum.
As for the rest, LordLimecat said it better than I could.
There's basically Windows, traditional Unix with X11 (with only Linux, *BSD and AIX left), and Unix + different UI (Mac OS X). Plus some embedded systems and some mainframe-like systems, but Unix is eating both.
We aren't exactly witnessing a Cambrian explosion.
If you can shoot 120 km straight up you can shoot less than twice as far if you pick a 45 degree angle. 240km rockets are nothing special for most nations who care about such things. If you have a hardened payload and safety isn't a major concern, solid-fuelled rockets are probably easier.
No one has done any serious work on (relatively) large hybrid rockets before. In that way it is ground breaking.
It may turn out that the reason why no one has done it before is that they don't work, of course. We will see in a few weeks.
I was under the impression that very few Windows applications were statically compiled... so why can't this just be updated in whatever shared object it uses again?
Because to avoid dependency hell and to compensate for the lack of package management, Windows applications come with private copies of the DLL's they need. If a flaw hits a common library like a JPEG parser you have to go through the file system looking for vulnerable versions and hope all the versions you have installed have fixes available. Or just wait till each application vendor gets around to issuing a patch for their particular application.
My gripe is how SELinux is expected to be able to confine malicious code which is already executing inside the kernel.
Ah right. No one should sanely expect this. I just got stuck on your explanation about locks; moving locks around wouldn't help, because the malicious code does not need to respect any locks.
It works like this: The malicious code invokes the syscall passing a structure, e.g. an inode but at the same time the malicious code starts a second thread which after a measured period (clockcycles) modifies the very same structure. By crafting this carefully the attacker can hit the "weak spot" between the security checks and the actual operation. It doesn't work every time due to obvious nondeterminism, but even a 30% hit rate will be exceptionally good in a mass attack.
If this was true, it would be a massive security hole rendering SELinux useless. SELinux isn't just a "last line of defense" thing which has a chance of reducing the impact of other vulnerabilities, it is an implementation of a Mandatory Access Control system. If you can come up with a generic way for a confined root user to bypass SELinux, by all mean publish! If it is as easy as you say it is, you should be able to come up with a demonstration in no time. Even a 1 in a million hit rate would be fairly easy to demonstrate and make you moderately famous in the security community.
The hosts file blocks whichever HOST NAMES you put in (and give an unreachable address). This works equally well with ipv6 and ipv4, and the number of host names doesn't magically increase with ipv6.
Which MLC drives are you using? I have so far had extremely positive experience with SLC drives for the enterprise and Intel MLC for laptops. So positive in fact that I'm tempted to try Intel MLC for the enterprise too.