Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: More like it's an opportunity for con men (Score 0) 358 358

Bitcoin has repeatedly demonstrated that it's nothing more than a ponzi - stoke up fears in a currency or appeal to their greed, wait for people to buy in and then exit with the different.

No matter how bad the Greek crisis gets, no matter how much of a haircut people get on their savings from any currency swap, it will still be less risk than bitcoin.

Comment: Re:I wonder why Oracle are doing this (Score 1) 328 328

I might not be paying them money directly but I'm certainly making them money. Developers and companies pay Oracle for tools, support, certification, training for Java and they do it because there is a demand for the language. If the brand is cheapened then ultimately it will hurt them in the wallet.

Same principle applies to Adobe and Flash. They make nothing from the Flash player but its all those eyeballs are what make professionals want to buy the dev tools that they do make money from. Cheapen the brand and it goes into decline.

Comment: I wonder why Oracle are doing this (Score 2) 328 328

The first contact many have with a new product is the installer. So what are companies doing to make a good first impression? Conning them into installing adware / crapware or changing their browser settings. It's insulting, it undermines trust and it cheapens the product by association.

I got so fed up of Adobe loading their updates will crapware like McAfee that I stopped installing it altogether. Likewise I've avoided other products which have started bundling stuff in their installers. I'm sure Oracle are compensated for promoting Yahoo from their installer but the reputational damage will suffer could be immense.

Comment: Re:Rule of thumb (Score 1) 296 296

Porting a Java application from Windows to Linux is normally as simple as copying the compiled .jar / .war / .ear over and just running it. The only reason it might not be is it contained JNA or if someone had hardcoded an assumption about the OS into it. Ordinarily neither would be the case and it is not unusual for people to be developing software which ultimately runs on big iron Unix from PCs at their desk.

Porting a C++ application from Windows to Linux means writing it with portability in mind from the very outset, sourcing which libraries you use, rebuilding the code from source and screwing around with the vagaries and differences of different compilers and toolchains. Even in the best of circumstances the code is likely to be plastered with #ifdefs and conditionally compiled code to deal with differences. The best bet would be something like QT which is fairly portable and has a large support library but it's still not as simple as Java.

Comment: Re:Deterministic Failure GOOD (Score 1) 165 165

PLCs would typically be programmed via IL or STL these days which are designed to be safe (no memory allocation, pointers etc.). Some PLCs even have multi channel execution where the same program is loaded and run on two or more different implementations and if the outputs don't match for the same inputs the PLC goes into error.

I should imagine that programming a car is way too complex for IL or STL and the temptation would be to use C++ but clearly that is a fraught issue, particularly in safety control systems. It probably doesn't matter at all if the media player uses C++ as long as it's running on a separate system entirely.

Comment: Re:Deterministic Failure GOOD (Score 1) 165 165

A segfault in this instance caused by a programming error, not a hacker. And no, they're not good things, particularly if we're comparing two languages, one which will blissfully compile that error straight into your production code and another which tells you about it at compile time.

Comment: A few years ago (Score 1) 51 51

Ubuntu hacked a Motorola Atrix so it ran Android when you used it like a phone, but plug it into a dock and suddenly it became a full blown Linux desktop. That's a concept ripe with potential. Doesn't have to be Android of course, but just the idea that it's a phone when you carry it around but you can use it as a computer too with a dock with some ports on it.

I'm kind of surprised that Microsoft haven't done something like that yet with an Atom powered phone. As for Ubuntu, I hope for their sake they are because I don't see much reason to use a phone running Ubuntu Linux otherwise.

Comment: Re:Memory Safe Languages As Countermeasure (Score 1) 165 165

Your solution to the problem is to try to kill the problem of bad developers by hiding it with the language.

It has nothing to do with "bad programmers". A programmer in one language can be expected to make the same number of errors in their code as a programmer in another. And they can be expected to have a similar spread of competence in their chosen language. It's about how many of those errors make it into the final product, the effort required to test / find / fix them, and the dangers (e.g. to safety, security) if they reach the final product.

C++ suffers from a whole class of problems that are minimal or even non existent in others - memory corruption, heap under/overflows, leaks, bad pointers. That's why languages like C# and Java took off - because companies can deliver a higher quality product in a shorter space of time.

It's also why C++ may find itself being sidelined by the likes of rust, swift etc. These languages offer comparable performance to C++ but will catch errors that C++ wouldn't even notice were errors. In particular rust has been explicitly designed to prevent pretty much every segfault that C++ could suffer from which in a safety system (e.g. running in a car) should be regarded as a good thing.

Comment: Re:Masters know their limitations. (Score 1) 342 342

No no no, you wrote a C++ compiler and you don't even understand why C++ is successful? It's because it still compiles all the old code. You DO NOT deprecate types that are in use in working code. I'm not sure "long double" is in fact used in any working code, but "long long" is THE 64-BIT TYPE so you don't fucking deprecate it.

This is a stupid justification. Gcc already has switches for different standards, -std=c++98, -std=c++11 etc. There is absolutely no reason whatsoever to stop certain functions, and language features from being deprecated or removed in new standards. If people still want to compile old code they can throw the switch in there and they get that functionality. If they don't, the compiler defaults to the latest version of the standard.

Comment: Re:Masters know their limitations. (Score 1) 342 342

The English language isn't defined by a committee which has the opportunity to fix longstanding issues with the language or deprecate redundant, arcane or dangerous functions and code. C++ does have this opportunity but never takes it. Instead it just heaps another layer of features on top of the old, we all sit around for years waiting for the compilers to implement this mess properly and by then another standard has come out.

A fail-safe circuit will destroy others. -- Klipstein