Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Comment bitcoin (protocol) vs BTC (currency) (Score 1) 71

Bitcoin is designed to make it very difficult to successfully get fake transactions into the accepted blockchain except on a very short and soon corrected basis - even if you had huge amounts of hashing power which this individual did not. An entire week of lame attempts? Boring.

Which is exycatly why bitcoin, the piece of software and its protocol, together with the underlying blockchain technology, are very useful *as of today*, despite the fact that BTC currency seems to have a complete random value.

Comment BTC vs bitcoin (Score 2) 71

I guess 20-30 years would be enough to prove that it' a viable currency in the long term.

even if BTC as a currency never gets any useful due to exchange rate instabilities,
bitcoin the protocole is already extremely useful.
(absence of a central authority being instead distributed across the whole network, and thus freedom to chose any provider for both ends (customer and merchant) of a transaction - both don't need to have accounts at PayPal, or at the Visa / MasterCard duopoly, etc.)

Comment And then before (Score 2) 71

Yeah, so far so good as long as you don't mind that BitCoin has lost 75 percent of its value in the last 22 months.

And before it has gained 400% in a few months, and before...
Seems that "a roomful of pigeons picking furiosly with their beaks at numpads" is the best approximation of BTCs value over time.

There would be riots if that was happening in a real currency market.

Such a thing in a real currency market would require everyone involved being on high doses of LSD.

More seriously:
- BTCs as a longterm storage currency isn't that much useful (unless you're a big gambler). Just don't store any longterm savings into this.

- bitcoin, the protocol, with all the technologies involved (blockchain) and thus all the software developed (as mentioned by parent poster) are all very useful and very well designed.
It already works today, and solves whole classes of problem (the simplest: it solves the problem of pushing around values (BTCs) without needing a central authority but instead distributing the control accross the whole network. The kind of simplification that SEPA brought to sending currency around between european banks, bitcoin protocol brings it to the world of online payment. Except at the scale of hours instead of days).
Instead of having companies working as single points of failure (Paypal, or the duopoly Visa / Mastercard) and requiring both side of the transaction (customer and merchant) being clients at the same company, bitcoin enables each side of a transaction to pick any solution of their liking no matter which, as long as both end point follow the bitcoin protocol. Thus there's no "bitcoin company inc." that a government could shut down, and no matter which payment processor a merchant has chosen, a client doesn't need to get bitcoin from the same place.

Comment perl5 in perl6 (Score 1) 161

perl6 is a complete overhall of the language. It isn't merely perl5++. They are similar, but they aren't compatible, which is why the perl5 interpreter will be maintained in parallel [so stated]. The perl6 interpreter [written in perl6, BTW], will be able to run perl5 code (e.g. it hooks on .pm or .pm6, etc.) and run a mix of the two. It will also be able to run python code, ruby, javascript, etc. if one wants to add the front end. So, in some ways, it's like .NET. You can run a program comprised of perl6, perl5, python, C, etc. all coexisting in one program.

Speaking of which:

- Inline Perl5 : hooks into the (still maintained) perl5 interpreter to run Perl5 code down to the latest bugs/weirdness.
- v5: (ab)uses the ultra flexible grammar and meta programming of Perl6 ('s interpreter - like Raduko) so that it can interpret Perl5 ('s language syntax).

Comment Perl5 in Perl6 (Score 1) 161

One of the goal (longer term, so don't expect it fully working with this preview release. Maybe neither with the final at christmas) is to allow other language being accessible to Perl6.

To quote one of the links:

But Larry was especially proud of Perl's ability to drop down into other languages. ("This is why we say all languages are really just dialects of Perl 6...") Python and Lua are even included in the Inline library. And Larry pointed out a new library that adds Ruby-esque rules, so exclamation points and question marks can be used at the end of identifiers. ("If that's what it takes to make Ruby programmers happy...")

- Inline-Perl5/ - Wraps a Perl5 interpreter as a module in Perl6 with data passing. Means perl5 and perl6 mixed *TODAY*. Works with compatibility down to all perl5's bugs/weirdness. Might still suffer limitation when passing some weird constructs around, and some speed limitation.
- v5 - abuse Perl6's ultra flexible grammar and meta programming to teach perl6 (...'s interpreters - like Raduko) to understand perl5 (...'s syntax). Should allow perfect passing of weird constructs, without any speed limitation. But is a new implementation of perl5 interpreter so might break some legacy code which unknowingly relied on bugs of the actual perl5 interpreter.

These 2 modules exist already and are used in the wild.

Comment Touch job ahead, all the luck! (Score 1) 686

Forking a large project is a tough, many-years job, it will need a lot more than just a few patches that weren't accepted to make it fly and it will need dedicated developers. But I think it's possible and I wish him luck.

There is a conceivable advantage to doing this. With some care, the forked linux kernel could be stabilized (something Linux really needs at the current juncture, frankly) and provide a goal for the FreeBSD linux emulation layer to go after, resulting in significant synergies between Linux and FreeBSD. Ultimately it might be possible to merge the device framework and solve the major problem that all kernel projects have of device-driver chasing by allowing developer resources to become more concentrated. That would be a difficult, but worthy goal.


Comment ubiquity and Git (Score 5, Insightful) 925

Is Linux successful? Debatable. It has success in limited uses,

These limited uses being "pretty much everything outside the desktop".

Servers, embed, high performance computing clusters, smartphones, robots, home appliances, etc.
And new uses still pop up on a regular basis.

Hardly a niche.

Though you probably are proud of explicitely using a non-Linux OS on your computer (Mac OS X ? Windows ?), fact is that you probably interact with a dozen of Linux powered device each day without noticing.

Linus accomplished a lot, but what groundbreaking thing has he done in the last 20 years?

Yeah, the guy has done nothing more that the Linux kernel in he's life. He's a one trick poney.
It's not like he would be ablto to do anything else like starting a distributed source control management (DSCM) that in practice almost replace any other SCM.
Oh, wait...

Without Linus to create Git, you probably wouldn't have had communities like GitHub emerge nowadays (or they would have tried to built on much less optimal technology. Github is born out of the specific feature that with git, forks/merges/rebases are cheap - a specific feature that Linus needed to build in order to be able to use git for the kernel work).

Comment Much more complicated (Score 1) 174

why would you need 120fps per eye when the human eye isn't really capable of seeing that much?

Actually it's much more complicated.
Depending on several factor, humans might notice 120fps.
(Mainly "dotted path" type of artefacts).

(The situation is different than audiophile's obsession with 192KHz which CAN'T be heard)

Comment Done with e-banking (Score 1) 317

The way the system should work is every user's card should have a number pad on it where they enter there pin. It should display the merchant's name, an amount of the transaction, and a transaction ID (ie the receipt). The card should then encrypt a message with GPG that is then transmitted to the card holders bank authorizing the bank to release the funds to the merchant.

...and that's how it works with lots of European banks' e-banking interface:
a completely offline device (either chip-card in a small calculator-like device, or card with keypad directly on them) are used to sign transaction (or simply the numbers they display. But you get to see the numbers).

European banks do it because:
- it's really the best possible security at this level of conveniance, thus less risk for their customer and thus less possible liabilities for the banks themselves.
- it's their own e-banking infrastructure, they get to do what pleases them (see point above for what pleases them).

That would be completely different with credit card payment:
- because the bank themselves don't get to decide. Instead they have to abide to whatever Visa and MasterCard imposes on them, and Visa and MasterCard are interested in a different point of balance on the security vs. conveniance scale (they need the credit card usage to be as easy as possible because they need as much transaction as possible to happen, which makes more money flow, which gives them more earnings from the percentages)

What some european banks have introduced is complete out-of-bound confirmation of transaction:
you get an SMS asking you to confirm the transaction that you do with the credit card. Even if the terminal is rigged/bugged, the SMS will show you that that the transaction amount isn't what its supposed to be.
Currently, that's not very convenient (slows down the procedure a lot), it's not very secure (all it takes is a rigged/bugged picocell spoofing the SMS), but at least it helps discover and intercept fraud much faster (wait, why am I receiving a confirmation SMS when I'm just sitting at work ?!?) and is a first baby step in the right direction (the user should rely on an external non-trusty device for displaying info about the transaction and asking PIN to sign the transaction).


Sadly, for the sake of convenience, some of these separate e-banking authentication are replaced... by smartphone apps.
Yup. Software running on *always online* devices that can be hacked.

All this because the user have already a phone in the pocket, and because the smartphone has a camera which is convenient for reading data from QR codes.


For the record: Bitcoin protocole also relies on the user signing a transaction that they see on their side.
Except that instead of getting checked by on single authority (that might have some sort of privacy policy), the check is distributed and each transaction is publicly broadcast for the whole network to store it in its distributed ledger (no true anonymity trades for no single point of failure).

Comment Towing & Electricity (Score 2) 323

What about when you have 6 people in it towing a boat/quads/whatever and fully loaded with luggage?

Now there's a funny thing with electrical vehicle and towing:

- electric motors are relatively simple and not the most expensive part in a vehicle (I mean when compared to a fossil fuel engine). There's nothing preventing you in putting more into anything. That's why recent Model S, and the Model X (and countless of small half-DIY things-on-wheel on youtube) are dual-drive.
Gives you twice the power, with not much extra cost.

- batteries are expensive, and a bit heavy, but once you already have the technology nothing forbids you to install more of it (beside the cost).

Put these two together and you find something very interesting : it's not completely impossible to add power to the tow.
- put an extra motor on the tow's wheel axis (dead simple, not that expensive)
- add a small battery (that's going to be expensive... unless the battery is modular and is your house's powerwall the rest of the time).
Now you're able to tow more without losing that much mileage.

The same would be an engineering nightmare with thermal drives, but electric drive brings it into the realm of possibilities.

In fact, that's exactly what European high speed trains are doing (random example: latest German ICE trains, Swiss ICN, etc.)
They don't have a locomotive/motor coaches.
Instead electric motors are incorporated into all the carriages. (adding extra electric motors is cheap).
The results is enormously powerful trains that can go very fast or climb steep.

Maybe, over the next decade, as prices for battery (and electric drive technology in general) get progressively lower, we'll be able to see mobile home that don't lower the mileage of the SUV they're attached too, because they have their own drive and electricity storage.
(At a very expensive price first, but the electric SUVs like Model X aren't really targeting the average person's budget anyway).

Comment Ski are long. Not for trunks. (Score 2) 323

I hate to break the bad news: but skis are rather *long* pieces of sport equipment.
You can't store skis in any trunk.

You either need a ski rack on the roof (as most other cars have options for, including the Model S telsa, and including all the cars I've ever driven).
Or you need a rack on the back of the car (as some people do with bikes, and as the few illustration I've seen of Model X tend to show).

But if you want to put skis *inside* any car, you need to lay flat some seats, at which point you lose the possibility of bringing more people together.
(You'll be only 3 persons: 1 driver and 2 passengers, and the rest of the space occupied by the skiing equipment.
Have been doing that personally for years).

Would be easier if all the passengers are only interested in bringing snowboard (shorter) and/or snowshoes/ice skates/snow blades/big foots/etc. (definitely shorter). But I'm a ski person.

Comment Fossil fuels (Score 1) 178

Reality: you can be fascinated by the technology, but realize that nuclear power is the most expensive technology ever invented by man.

Of course if plants burning fossil fuels (Coal, Gaz, etc.) don't need to be held accountable for the countless respiratory disease that they cause by pumping out tons of pollution in the atmosphere.
(and that's just the direct effect of putting shit into people's lung by polluting the air. I'm not even starting on the impact on global warming/climate change).

much less storing the waste for hundreds of years.

yup, let's panic about a couple of tons of radioactive waste.
it's so much better instead to rely on a method that constantly dumps countless tons of shit, diluted into the atmosphere (hey, no single waste storage place to be bickering about !) and eventually stored into the lungs of the general population.

Nuclear power == corporate pork and fluffing Tom Swift fanboys.

Coal/Gaz/etc. power == using general population's lungs as sewer system.

Yup. Nuclear energy isn't perfect. Indeed it does have its problems. I agree we could do better (hydroelectric, solar, wind, etc.).
But compared to what is currently used in lots of place, nuclear is *definitely less worse*.

You always need to thing about *what other technologie* one specific energy is competing.
What is the alternative.

As much as you would like the alternative to be wind farms, and solar panels, the reality is that the alternative against which nuclear power is competing is mainly burning fossil fuel and filling the atmosphere with its waste. On a scale that is order of magnitude more polluting and problematic than nuclear for a given amount of output energy.

Comment Car analogy (Score 1) 300

It should be obvious to most on here why a car analogy fails in regards to opportunities with programming and automation.

Also, you might notice that:

- regarding cars: currently only a few big motor companies are making money by *making* cars. Most of the other people that make money with cars, make that money by *using* car. You don't need a special custom car built for your business.
At most, you need your company/start-up/mom-and-pop-shop's logo on the car, and that's about it.
Thus from that point of view, indeed teaching all student how ignition works isn't the most critically important skill.

- regarding computers: that where the difference starts. Not only do big companies make money by *writing* code (Google, Facebook, etc.). Also all the small player that make money with computers need some kind of specific code.
Start-ups, small shops, etc. usually need at least some solutions custom developed for them. Might be as simple as a webshop setup for a small familial business, might be an ad hoc web platform for a new kind of service.
The company/start-up might not do it all on their own, but they at least need to have a vague idea about what could be done, and there's need for someone to actually write/develop the thing in the first place.

In short, against the car analogy: it seems there's a lot more money to be made by small entrepreneurs by harnessing their ability to develop an App or a web platform, than by harnessing their ability to understand how ignition works.

Now, you have to factor a few other things in the mix:
- IT jobs are the first that companies try to outsource. (with variable success. but that won't prevent that the company will first thing to hire someone in new dehli before thinking of hiring junior who happens to have learned coding in school and has some experience making apps)
- technician able to fix cars are required where the cars are physically present. Mechs able to fix cars aren't going to be easily outsourced.

So in a way Jeff Artwood was right but for a reason he didn't think about: kids need to have an idea about coding as much as they do need to have an idea about a car's internals: both might get handy.
- There's still tons of money to be made by small entrepreneur designing App, webservices, etc.
- There's job security in being able to fix cars.

Saliva causes cancer, but only if swallowed in small amounts over a long period of time. -- George Carlin