The energy density of compressed hydrogen is bad enough as it is without making it even less dense by putting lots of liquid molecules in between. Remember the breakthrough isn't that this liquid can increase the density of stored carbon, it's that it can selectively capture CO2 from the air.
Of course there is already another way to store hydrogen very densely in liquid form at room temperature, but separating it from the oxygen is the tricky part:)
So what is the IoT angle here? As far as I can tell the malware was placed on the drive of the bodycam as a file (it's the only infection vector that makes sense in this case), and that can happen to any USB drive. While I'm sure it's possible to design a worm that can infect IoT devices, this doesn't seem to be an example of one.
OpenBSD is probably unbreachable but it's terribly useless as anything but a firewall; to use it as a general OS, you have to turn a lot of its security precautions off. Linux (and by that I mean "GNU/Linux" e.g. RHEL, SUSE, Debian; not Android) gives us a healthy balance between usefulness and security. That's why almost every webserver runs Linux.
So OpenBSD makes a poor "general" (workstation?) OS, which is why "almost every webserver runs Linux"? Huh? Something being used for running as a server doesn't (and probably shouldn't) have to run well as a general OS.
Sure really tight system security probably would make a desktop OS more difficult to use, but the same doesn't apply to servers where security is more important.
Black Cabs don't have a legal monopoly on taxi services in general, only metered street-pickup taxi services. There's already a thriving "mini-cab" service in London and the rest of the UK where rides must be called for (by phone or at a mini-cab office) and a fixed price is given at the start of the journey.
In London mini-cab drivers do have to be licensed, but the licensing requirements are much less strict that for black cab drivers. Seems like Uber drivers just need to pick up mini-cab licences.
Ah but you see Java has saved the day, for instead of a dangerous code execution buffer overflow condition the program simply quits out with a safe exception!:)
Alright, the court case is still on-going to decide if reimplementing an API is fair-use. If it is fair-use it would put us back to where we were before, if it's not then that's set a precedent where there is no fair-use protection for someone to re-implement an API, which again is what WINE, Mono, GNUstep and many other projects do.
But it's not resolved because if it's fair use to re-implement an API then everything's fine. The problem is if APIs are copyrightable with no fair-use exemption to use/re-implement then that's an issue, because anyone who writes a compatibility layer or service that adheres to a 3rd party's standard is just one copyright claim away from ruin despite the actual implementation being an original work.
They didn't make something that worked similarly to Java - that would have been OK, C# is similar to Java after all. They made something that was *identical* to Java. If they didn't want to be sued they should have made their own API and their own language
What it comes down to is should APIs be copyrightable. Google created their own implementation of the Java API, if companies are allowed to copyright APIs then you can kiss WINE goodbye immediately, anyone wanting to implement an existing API would also be in trouble, and you might not even be able to create a program that even accesses an API without explicit permission.
That means that Google must comply with Oracle's terms within the limits defined by law.
But Google doesn't use Java, they use Dalvik/ART, which aren't written by Oracle and therefore don't have Oracle's ToCs attached to them.
They do happen to be compatible with Java, but if you are allowed to copyright APIs (which is what Oracle are pushing for) then that would be absolutely insane for the IT industry, as you wouldn't be able to implement an API (or possibly even access an API) without the permission of whoever wrote that API.
Laser is still expensive, but it can do something inkjet can't: it can print heavy blocks on cheap paper without ruining it.
You say that, but we had a colour laser printer at work that would jam (properly crumple up the page in the mechanism) if you tried to print a large block of a dark colour.
Black would be fine, as that's just K, but any large fill that required several of the toner colours physically wouldn't print.
Any brown dwarf would be at least a few light years away (or we'd know about it), and at New Horizon's current speed of 52,000 mph it would take around 13 thousand years to travel 1 light year. New Horizon's power source is due to run out in 2030.
The flight computer wasn't confused, it correctly detected an error in the speed readings and then, as designed, returned control to the human pilots. It could just have well put the plane into the correct pitch/throttle settings itself, but it wasn't designed to.
Also a senior pilot in a non-chaotic situation (for example at a remote control station) would have had a much better chance of maintaining situational awareness over what was going on and so better spot mistakes like pitching up too far.
In the Air France 447 it was the (junior) co-pilots who became confused though, not the flight computer. In a more automated plane the autopilot would, in the same situation, have put the plane into a safe pitch attitude and thrust setting (the correct procedure for loss of airspeed indication) and called for the senior pilot/operator to fix the issue.
But the thing is there's enough evidence that the plane remained flying to discount a sudden catastrophic failure; Military radar picked it up making several precise waypoint manoeuvres well away from it's planned flight path and the satellite comms gear kept responding for 7+ hours after the plane went missing.
But the first step would have been to radio ATC and request emergency clearance at the nearest runway, as without that the pilots would have no way to know the status of nearby runways and whether it would be possible to land.
I could imagine some electrical problems from a large number of cells catching fire or 'gassing' the whole airplane within seconds.
But of course that would either quickly cause the aircraft to crash, or to just stick to its original autopilot headings if only the crew were incapacitated. Military radar caught it making precise manoeuvres around several waypoints well away from it's original flight plan...
The standard procedure, as far as I know (not being an expert), is upon noticing the fire, the pilots would have shut down all the circuits on the plane in order to find out if one was responsible for the fire.
They don't turn off all circuits, only non-essential ones. For example as in this crash caused by an in-flight fire the standard procedure is to switch off power to the cabin but not the cockpit, as without power to the cockpit you'll barely be able to fly. The radio was also kept on at all times as you're less likely to be able to make a successful emergency landing without being able to talk to ATC to make sure the runway is clear and prepared.
It's not telling students to use recursion to output that number sequence, it's asking students to read and understand a bit of code that does it. Being able to read and understand other people's badly written code is absolutely essential in todays software industry...
Slashdot Mirror
The energy density of compressed hydrogen is bad enough as it is without making it even less dense by putting lots of liquid molecules in between. Remember the breakthrough isn't that this liquid can increase the density of stored carbon, it's that it can selectively capture CO2 from the air.
Of course there is already another way to store hydrogen very densely in liquid form at room temperature, but separating it from the oxygen is the tricky part :)
So what is the IoT angle here? As far as I can tell the malware was placed on the drive of the bodycam as a file (it's the only infection vector that makes sense in this case), and that can happen to any USB drive. While I'm sure it's possible to design a worm that can infect IoT devices, this doesn't seem to be an example of one.
OpenBSD is probably unbreachable but it's terribly useless as anything but a firewall; to use it as a general OS, you have to turn a lot of its security precautions off. Linux (and by that I mean "GNU/Linux" e.g. RHEL, SUSE, Debian; not Android) gives us a healthy balance between usefulness and security. That's why almost every webserver runs Linux.
So OpenBSD makes a poor "general" (workstation?) OS, which is why "almost every webserver runs Linux"? Huh? Something being used for running as a server doesn't (and probably shouldn't) have to run well as a general OS.
Sure really tight system security probably would make a desktop OS more difficult to use, but the same doesn't apply to servers where security is more important.
Black Cabs don't have a legal monopoly on taxi services in general, only metered street-pickup taxi services. There's already a thriving "mini-cab" service in London and the rest of the UK where rides must be called for (by phone or at a mini-cab office) and a fixed price is given at the start of the journey.
In London mini-cab drivers do have to be licensed, but the licensing requirements are much less strict that for black cab drivers. Seems like Uber drivers just need to pick up mini-cab licences.
Ah but you see Java has saved the day, for instead of a dangerous code execution buffer overflow condition the program simply quits out with a safe exception! :)
There's a spacecraft depicted in Neal Stephenson's book Anathem that strikes me as already easy to conceive.
That ship was actually based on a real concept.
(Also features in KSP :)
Torrent link ;)
Even a stopped clock gives the right time twice a day.
Ok then, list a few examples of where it's fair-use to re-implement an API, and where it isn't.
Alright, the court case is still on-going to decide if reimplementing an API is fair-use. If it is fair-use it would put us back to where we were before, if it's not then that's set a precedent where there is no fair-use protection for someone to re-implement an API, which again is what WINE, Mono, GNUstep and many other projects do.
But it's not resolved because if it's fair use to re-implement an API then everything's fine. The problem is if APIs are copyrightable with no fair-use exemption to use/re-implement then that's an issue, because anyone who writes a compatibility layer or service that adheres to a 3rd party's standard is just one copyright claim away from ruin despite the actual implementation being an original work.
They didn't make something that worked similarly to Java - that would have been OK, C# is similar to Java after all. They made something that was *identical* to Java. If they didn't want to be sued they should have made their own API and their own language
What it comes down to is should APIs be copyrightable. Google created their own implementation of the Java API, if companies are allowed to copyright APIs then you can kiss WINE goodbye immediately, anyone wanting to implement an existing API would also be in trouble, and you might not even be able to create a program that even accesses an API without explicit permission.
To come back to your metaphor just because something implements the IDuck interface doesn't mean it's the same kind of duck.
That means that Google must comply with Oracle's terms within the limits defined by law.
But Google doesn't use Java, they use Dalvik/ART, which aren't written by Oracle and therefore don't have Oracle's ToCs attached to them.
They do happen to be compatible with Java, but if you are allowed to copyright APIs (which is what Oracle are pushing for) then that would be absolutely insane for the IT industry, as you wouldn't be able to implement an API (or possibly even access an API) without the permission of whoever wrote that API.
Laser is still expensive, but it can do something inkjet can't: it can print heavy blocks on cheap paper without ruining it.
You say that, but we had a colour laser printer at work that would jam (properly crumple up the page in the mechanism) if you tried to print a large block of a dark colour.
Black would be fine, as that's just K, but any large fill that required several of the toner colours physically wouldn't print.
Basically laser printers can be crappy too.
Any brown dwarf would be at least a few light years away (or we'd know about it), and at New Horizon's current speed of 52,000 mph it would take around 13 thousand years to travel 1 light year. New Horizon's power source is due to run out in 2030.
If it's good enough for Picard, it should be good enough for you! :)
The flight computer wasn't confused, it correctly detected an error in the speed readings and then, as designed, returned control to the human pilots. It could just have well put the plane into the correct pitch/throttle settings itself, but it wasn't designed to.
Also a senior pilot in a non-chaotic situation (for example at a remote control station) would have had a much better chance of maintaining situational awareness over what was going on and so better spot mistakes like pitching up too far.
In the Air France 447 it was the (junior) co-pilots who became confused though, not the flight computer. In a more automated plane the autopilot would, in the same situation, have put the plane into a safe pitch attitude and thrust setting (the correct procedure for loss of airspeed indication) and called for the senior pilot/operator to fix the issue.
But the thing is there's enough evidence that the plane remained flying to discount a sudden catastrophic failure; Military radar picked it up making several precise waypoint manoeuvres well away from it's planned flight path and the satellite comms gear kept responding for 7+ hours after the plane went missing.
But the first step would have been to radio ATC and request emergency clearance at the nearest runway, as without that the pilots would have no way to know the status of nearby runways and whether it would be possible to land.
I could imagine some electrical problems from a large number of cells catching fire or 'gassing' the whole airplane within seconds.
But of course that would either quickly cause the aircraft to crash, or to just stick to its original autopilot headings if only the crew were incapacitated. Military radar caught it making precise manoeuvres around several waypoints well away from it's original flight plan...
The standard procedure, as far as I know (not being an expert), is upon noticing the fire, the pilots would have shut down all the circuits on the plane in order to find out if one was responsible for the fire.
They don't turn off all circuits, only non-essential ones. For example as in this crash caused by an in-flight fire the standard procedure is to switch off power to the cabin but not the cockpit, as without power to the cockpit you'll barely be able to fly. The radio was also kept on at all times as you're less likely to be able to make a successful emergency landing without being able to talk to ATC to make sure the runway is clear and prepared.
Reality TV space mission? It's not rocket science!
It's not telling students to use recursion to output that number sequence, it's asking students to read and understand a bit of code that does it. Being able to read and understand other people's badly written code is absolutely essential in todays software industry...
Because System.out.print(n);