stop repeating this nonsense about technology not disrupting peoples lives. Yes, over the course of several decades the economy replaced those jobs. In the meantime millions were without work. There's a reason why the Luddites existed. That word has meaning beyond an insult. There was nearly 60 years of joblessness following the industrial revolution before other tech caught up. Google it. Read some history. Jeez.

I agree the solution isn't to go back on technology though. It's socialism. Plain 'ole socialism. When we don't need these people to work we don't just let them starve while we all take turns seeing who can make the 1% the happiest. And btw, I said _socialism_, not communism. And not a fascist dictatorship that occasionally publishes a pamphlet with something written by Karl Marx either...

if he ACTUALLY did any such thing the FAA would have issued a notice requiring aircraft WiFi

You obviously didn't read the search warrant.

First, it states that in previous interviews (in Feb, and I'll bet the FBI has audio records to support that), he had described connecting to the network using Ethernet connected to a "Seat Electronic Box" ("SEB") which is mounted under the seats. So, WiFi has nothing to do with it. In the same interview, he said he understood the legal ramifications and would not access airplane networks.

The warrant goes on to state that the FBI inspected the SEBs around the seat he occupied on his 4/15 Denver to Chicago leg, and found signs of damage and tampering.

That, along with his history and the tweet regarding being on the flight and suggesting he could tamper with the flight systems seems to me to be reasonable grounds for a warrant.

And, I hope he's prosecuted. Also in the Feb. interview, he admitted actually tampering with flight control systems. It's one thing to find a vulnerability and try to get it addressed. It's quite another to actually make use of that vulnerability during a flight, placing the public at risk.

If it works as well as hoped this will save a lot of
big birds from an early demise.

Big fans rotating like heck are an astounding challenge to keep intact
and maintain. Not that these will be any easier but "Big Bird's" yellow
feathers will be safer (one can hope).

Just because a piece of software is old, doesn't mean it's suddenly doesn't do its intended function.

I'm not sure I'd be shocked by the effort that people make to keep old software running,. You mention PDP emulators, but how many people here use DOSBox on a regular basis to play old games.

Emulators are just one way do keep old software running of. The other way if the source is around is to keep updating the software for new platforms but avoiding too much feeping creaturism if you can. That's pretty much where I'm at with doing ircd work, keep the code updated for modern systems(with their own OS specific quirks) so it continues function.

It seems like people just want new and shiny software just for the sake of having new and shiny. New and shiny code however doesn't have X number of years of being used as production and all of the WTF bugs have long been squashed.

Meh.

I suppose it depends on what you want to do with it, and what you see Java's future as a wholly-owned subsidiary of Oracle is.

I was studying programming in college when the hype for Java began. We were using C and C++. What was true then still holds true today, in that in C/C++ you can write operating systems and conventional programs, but in Java you are limited to conventional programs. Java has the theoretical interoperability feature between OSes and hardware platforms, but in practice there's a lot of customization to make programs actually do this, and if one has to write versions for several platforms, it's not a whole lot more burden to compile those and distribute binaries instead of Java runtimes.

  I second your opinion. When we had 1.44meg floppies, it was extremely important to have shared libraries. By now, 20 years later, we can have 8 terrabyte disks on our desktops, and 32gigs of ram. Yes, for shared system libraries (I/O, system calls, etc.) but statically bound libraries for the rest. If I upload a package and it is defective, I want to only remove that package, and retain the rest. I also want to isolate that package to certain directories. I suppose, that's what containers is about.

As for servers, I've always liked the mindset of putting as little as possible on the production server beyond what its job is. Hell, the idea of statically-compiling everything to allow one to eliminate libraries, let alone compilers on the production box, appeals in that if someone does break in there's a lot less they can do once on there. Java for server-side applications flies in the face of that, there are more general-purpose tools on the server rather than less.

I'm aware that I'm not in the majority for this stuff, and I didn't make programming my profession anyway so perhaps even I should be taken with a grain of salt, but it seems like in this speed to push features we've taken steps backward in real system security, and we're being bitten in the ass by it with ever increasing frequency. The very choice of programming language appears to be fundamental to that.

This is why "no fault" insurance was invented. Even with people, the liability in traffic accidents is often complex. Require no-fault insurance, you insurance is responsible for you, mine is responsible for me, and you are basically done - at least as far as car insurance is concerned.

What may be left is civil liability. If a manufacturer produces a genuinely faulty product, they can be sued in a completely separate action. The laws are already in place for that. The problem I see is the exact opposite of what you are worried about: People will sue, regardless of the quality of the product. Because bad things aren't supposed to happen, and if they do, someone must be to blame.

So someone without insurance t-bones my autonomous car, and I want compensated. The other driver is broke, so I sue my car manufacturer. Stupid, but entirely possible under US law. Loser pays would be the simplest solution: if you file a stupid lawsuit, you'll be paying the other side's legal costs. In the case of class action suits, the attorneys for the class should be liable for the loser's legal costs if they lose.

Before any company brings autonomous cars to market, the US tort system has got to be fixed.

It isn't vague at all, cerberusti is exactly correct and the AC is a maroon.

"Work for hire" means employee. It doesn't matter what you want it to mean; look up the legal precedents. Contractors are exactly what is _not_ "work for hire," it is business to business contracted work. Basically, the opposite of "work for hire."

There is no ambiguity; you have to have an express assignment of copyright for it to transfer. The contractor owns all their own IP. What the client gets is an implied unrestricted license. That gives them certain rights; you can't stop them from using what you made, because they paid you to make it, but that isn't the same as granting copyright. And a copyright assignment that is buried in the contract is actually not enforceable. You have to have a separate document that is only the copyright transfer. You have to have a signature that is just for the copyright, or else it is not expressly agreed to, it is just an unenforceable extra condition. The copyright assignment can require another document to have been signed in order to take effect, though. So that is how it is done, and that is why there is more than one thing to sign when you have a lawyer do this stuff for you.

The funny part, yeah, consulting contracts often do claim to state the ownership, but that isn't a valid place for it, and the contractor actually still owns that code. It doesn't come up very often, though, because if you try to use that to screw somebody over, you'll be engaging in an unfair business practice and that will preclude you from bringing an otherwise-valid lawsuit regarding the matter.

The easy way to remember it if you don't want to learn the details, the copyright designation is based on who the legal employer is, not who paid for the work. Paying for the work just means you have to be allowed to use the thing that was made for you. If you want to also own the copyright, you're buying that separately the same as if it was made for somebody else.

Just wiki "work for hire" before trying to get pedantic and "stepping in it."

But in the article, as an employee there is no way for him to end up with copyright. Even if it was done at home, since it is clearly related to his work, they own it.

My advice for him, if you're not ready to be a contractor, and you're not ready to start your own company, just write these ideas down in a notebook. You're not in the right situation to be writing speculative for-profit apps that take advantage of your employer's platform, because you're also writing those for your employer. If your company actually wants you to do this, they'll give you the documentation you need, but make sure you're really well trusted by management. If you're just a regular Jr developer, don't even ask. Just write your ideas down so that you can think about them more later, and learn about which still look good later.

$30 or so? I can easily drive to SF from LA on ¾ of a tank, which would be about 30 bucks. Why pay more than that? I get parking in SF might be terrible and costly, but depending on whom you are visiting driving is really the way to go.

This is hilariously dishonest.

Conventional taxis don't have to go out of business - that's a strawman/misnomer. Why don't they provide their own apps to provide service to riders? Oh, right. Uber is doing what taxi services refuse to in a lot of instances. Uber isn't the problem here, but old outdated legislation is.

Taxi services don't operate 24/7 with 100% coverage, that is and never can be the case anywhere. Meanwhile, uber is opening up to other competition and enabling better coverage than the taxi services themselves provide.

here in OZ they are pushing the boundaries of what is legal for "taxi" services, so I would be very surprised if that were not the case in other countries/states juristrictions.

I won't say hobbling. I have both the fx-8150 and the fx-8350 and they are both de finally behind on the curve when it comes to technology. Both of these processors where gifted to me by a friend who was sick of always being behind on the curve when it comes to AMD. He hopped over to Intel with a couple of i7's last year.

I'm convinced unless something changes an AMD gets on the ball with this release, my current AMD systems will be the last AMD systems I own.