Slashdot videos: Now with more Slashdot!

For the record, a Cryptocurrency isn't called so because it's hidden (indeed it's not).

It's called so because is relies a lot on *Cryptography*: digital signature, public keys, message authentication, etc. All these are necessary for the distributed nature of cryptocurrencies to work reliably.

As for "state controler Fedcoin": Sorry, no. It doesn't work that way. The whole point of cryptocoins is to be distributed accross the network, so that there isn't a signle entity that has single hand control over everything else. That's *why* they rely on a transaction ledger (Blockchain) distributed accross the whole network. State control is impossible this way.

For the record, AMD is also moving toward a hybrid stack for the Linux drivers:
- the same opensource kernel driver is used every where.
- the only difference is that either you run the official catalyst OpenGL implementation from AMD on top of it. Ot the opensource Mesa Gallium3D tracker.
- same goes for video (either a VA-API implemented by catalyst, or the various Gallium video state tracker).

So except for the 3D and Video, everything else is opensource and work is shared.
From the development point of view, AMD hardware is faring very well. GP doesn't need to be afraid.

There is also some potential increase of security:

Unlike (nearly) every card(*), the phone is a device that has its own display and input interface.
Meaning that you don't need to trust the payment terminal(**).
- No risk of skimmer trying to read you PIN: you're typing it into your own phone, not on the terminal which could have been hacked/modded.
- You can trust the amount displayed (again, you are reading your own phone's screen, so even if the terminal is hacked to display a lower sum and actually bill a higher sum, you'll notive the discrepancies).

Also, the phone has connectivity, which allows out-of-band confirmation for the transaction (***).

Thus, the device is protected against fraud that could menace a classical card.
- hacked terminals showing bogus transaction amounts, or trying to record your PIN.
- hackers trying to relay a transaction (small amount are "tap/swap only": no signature neither PIN asked. It's possible to use a powerful antena pointed at a wireless credit card to remotely use it and relay communication to a terminal).

Saddly, the phones have their own problems:
- they eat batteries like candy (even wireless credit card transaction are remotely powered by the terminal. Whereas a dead phone is dead and can't be used for paying).
- again, they are conencted. Which means that they could be compromised themselves. (Specially since people tend to install tons of crap).

-----

(*): I've seen banks issuing cards used for e-banking that have a build-in screen and keypad. Similar devices are in theory possible on a credit card.

(**): lots of e-banking card reader do exactly that: you can check on the screen what you are asked to sign.

(***): That's a security feature that's also offered by combining classical credit cards and separate connected device. I can be asked to confirm by SMS / by voice call when the bank detects unusual traffic on my credit card.

Which was, by the way, the motivation for Palm buying BeOS: for their technology, to use it as a way - for exemple - to play MP3 in the background of very low-power machines that were not even designed for multitasking.
And thus some of the multimedia component made it into PalmOS 5.x

Saddly, Palm themselve didn't manage to stay successful.

In my experience, the quality of maps available on OpenStreetMap is good enough (and sometime even better, they have better bike- and hike- trails, whereas Google concentrate all their efforts in making their maps the best ever for cars).

Navit provides a decent enough routing capability (and comes with extra data, like speed limitations, speed cameras, etc.)

So even if it's not Google-level quality (except for the hike & bike exception mentionned above), it's good enough for me to get around.

Of course, depending on where you live, "your mileage may vary". Here around (central europe), other netizent spend great effort fixing OSM and it has good quality data. (sometime better/more up to date than the paid-for GSM maps of our family car).
Some other place might be better (places that Google doesn't even care covering) or worse (region with less community involved in OSM).

So in other words, for me: I bothered to have a look at OSM, and already works at getting me from point a to point b. (Thanks to the fact that all my a and b points tend to lay in region with online communities paying attention to OSM) (even more when the path between a and b is non-car. Then OSM rocks).

Hey, while you're at it, why not including also a JPEG decompression in kernel? That's useful for Webcams! And throw H264 while you're at it! That's gonna be great! except... not.

Such a hackish idea was actually done with some newer USB webcam drivers in V4L. Once resolution increased to 640x480 and above, USB webcam, in order to circumvent the limited bandwitdh on USB 1x, started compressing frame as JPEG in hardware and streaming the compressed stream to the PC.
Back then, the only way to get useful output out of V4L (designed to provide raw images like on older cams) was to embed a whole fricking JPEG decompressor inside the kernel driver (that's what the spca5xx driver did back then).
The thing wasn't the most stable thing ever. The jpeg decompressor wasn't very resilient and fault tolerant. If USB transmission got corrupted, the decompressor could barf. That barfing happenned while in kernel space.

Luckily, V4L2 was later introduced, which also handle compressed stream, and nowadays all the peculiarities are hidden behind a user-land framework like gstreamer (which handles the dirty low-level interraction behind the scene. Including compressed streams, including non-USB webcams like firewire, etc.)

Same goes for sound:
mixing is a rather high-level task which should be kept out of the kernel into a separate userland daemon, because that's the sane solution.

You DON'T try implementing rsync in kernel space. Only block devies and filesystem. Higher level stuff goes into userland software.
You ONLY implement in-kernel webserver as a proof of concept or for some corner cases. Apache and the like remain separate stacks.

Thus:
You keep video decompression and sound mixing out of the kernel too.

Depends in which jurisdiction you happen to live. In the US, yes maybe.
In other countries depends. It might range from:
- laughing of and throw the **AA's letter in the bin
- to "Sorry guy, but I actually paid the necessary tax in my country" (Russia has a centralised - and very cheap - copyright tax, left over from the soviet era. In France, there's jurisprudence that the "blank media tax" imposed on most sold blank media is supposed to pay back for anything that you download and store there. Etc.)

And yes, they could do it. (I doubt they'll do it any time soon in practice. But in theory that's entirely possible for them to implement. A la Facebook: "This list of friends are also checking/following[*] this page" - [*] meaning that you once clicked by mistake on the link and now this incident will be used as a tool to pull as many of your friends as possible).

Want to trust your communication channels ? Then you MUST use end-to-end encryption, a la OTR. The only way to transmit your messages in a completely tamper proof way. The only way to be able to trust the source of the message.

If low latency in professionnal audio setting is your target, then there's already specialized software for that: JACK.
It's specially designed for what you want, and as widespread usage in the field.

Or might as well go for a hardware solution.

Use the right tool for the right job. Otherwise you end up trying to cram extra requirement into a tool which wasn't designed for it.

There are even special distribution which are geared toward pro needs and are tuned with this kind of tools.
(Dynebolic as an example)

Yup, Amiga had hardware sound mixing (4 channels in this case. that's where 4-channel MOD where born from).

PC from back then had some form too. (High-end sound cards like Gravis UltraSound were basically multi-channel, like souped up version of Amiga. Creative Sound Blaster AWE could mix samples as part of their wave table synthesis or even stream "instruments" from the main RAM, i.e.: actually stream a second audio track and mix it - that's what most player back then used to do to avoid grabbing and locking the "waveout". Starting from Creative Sound Blaster Live! each software sending its own separate stream and the card mixing them was the norm, ...)

Hardware sound mixing was the norm on most high-end gaming machines. It's only recently that "only a glorified DAC" that were common on laptops and office box started to become the norm in high-end stations, once the CPU had enough omph that sound processing become an insignificant burden.

Hence the need of sound mixing daemons, hence the rise of pulse audio in linux world and hence the equivalent whose name I've forgotten in Windows.

Networked sound playing is just an incident of pulseaudio being a sound router. It's a nice feature, but that's not what pulseaudio was basically written for.

There are lots of situations where sound is routed to something which isn't the usual ALSA driver:
- lots of headphones/microphones now are USB. They are not another channel on the same soundcard, they are a completely different sound driver. Switching when pluging a headset is not something which is trivially done in ALSA without special support of software.
- bluetooth, which is VERY common on portable devices (but also might be usefull on dekstops) isn't even a kernel driver. Sound is handled by a deamon communicating with the bluetooth stack. It has much more in common with networked sound than with ALSA.
- recording the output of another program becomes much more trivial if there's a sound router handling the redirection, instead of needing some special support in software.

Pulseaudio doesn't require any special support. It can present an ALSA target to any ALSA-enabled software. Most current software don't even have a pulseaudio plugin, they just open the default ALSA device which happens to be one pulseaudio listends to and that just works.

Why the fuck do you want to round a *sound mixer* inside your *kernel space* ?! Do you run your video decoder and webbrowser there too ?
I prefer to run unnecessary things like sound as daemons in userspace. Thank you very much.

And you're still free to disable pulseaudio and use dmix instead, if you want.
Now indeed, for an init system, it's a bit more complicated to leave complete choice to the end user. Some specialist distro like Gentoo are able to offer you to switch between their default OpenRC and whatever you want.
But the amount of work and risk of bugs in untested paths is rather high. So don't expect other distros to offer instant switch between systemd and upstart.

Instead of being vulgar, maybe you should ask yourself why so many distributions are switching to systemd.
Maybe, part of the reason would be that systemd solves actual real world problems that these distributions need fixed.
Maybe that's because systemd people and Lennart Poettering actually ship code, instead of just sitting the whole day bitching and cursing on internet forums.
Maybe if you didn't spent all your energy on whinning about systemd, and actually tried to *DO* something, to *FIX* the problems, and write an actual good solution, maybe your solution would be the one picked up by distros.

Also please try to avoid making confusion between the actual piece of code that runs as PID 1 (which is indeed confusingly called "systemd") and all the other pieces of code that add the functionnality mentionned in all systemd articles (these pieces of code are all members of a project which is also called by the same name "systemd", but all pieces of code are completely different deamons like "networkd", "journald", etc.). In other words, it's not the PID 1 that get stuffed with innapropriate functionnality. It's the people who wrote the PID1 that are also writing other daemons for extra functionnality, all different parts of the same project.

And the low tech problems:

- Lost passwords:
user encrypts everything. user lose key/password. user is locked out of encrypted data.
Today, with the help of some hacking (e.g.: wiring a vintage floppy reader) you can access any old data that you dig up from your basement. 25 year from now, you won't necessary be able to find the credential you might need to access data that you encrypted today. And no hardware hacking will help much (unless by that point quantum computing has progressed to the point where rigging a machine to decrypt the lost data is possible. And the cryptographic algo is quantum-forceable).

- Kept password:
user is afraid of the former situation. And decides to write down passwords. On post-its left on the screen. In plain view for everyone.

It might surprises you, but don't trust "Monster Cable": you don't actually need a cable as thick as the charger of a Tesla car to carry a digital video signal.

Yes, most HDMI cable are stiff. No, that's not a requirement. Thiner and/or flatter, and more flexible HDMI cable to exist.

I was actually surprised that there are USB host connectors on this thing. I would have expected it to use bluetooth keyboard if any one needs one. (And I imagine it more used for none-keyboard tasks).

Nano wireless receivers for the occasionnal keyboard need, and other similar USB nano devices, might do the trick.

It might surprise the "Monster Cable crowd", but HDMI cables don't necessarily need to be thick enough to be able to carry 16A current.

In fact, I have a flat HDMI cable which very thin and flexible, enough so because it's a roll-up. And it works nicely this way. That's already a cable that won't induce much more drag than your old-school PS/2 cable.
(And there are ultra thin sub-2mm cables on the market too).

Once upon a time, mice use to be wired.

Before the era where everybody uses mouse that talk over bluetooth or some proprietary variation of Wireless USB and that uses batteries that die every once in a while, there used to be a period where USB and PS/2 cable dangling from the mouse to the main machine where the norm.

And nobody found it problematic back then.