Slashdot Mirror

The idea of a decentralized authentication mechanism, the one underlying all crypto currencies, is very appealing. The people behind bitcoin and the blockchain knew it was an experiment, and recently they labeled the experiment as "failed".

Many will now jump on the bandwagon, but it was fairly obvious from the beginning that the blockchain has some deep flaws: huge energy expenditure, the 51% attack, the very limited bandwidth, and more. People who "invested" in cryptocurrencies were gambling. Some made out like bandits, but most have or will lose.

Nonetheless, the blockchain idea should continue to be researched. It is a very smart idea in spite of the flaws.

This article touches on many of the overall issues, implicit in the "question", as it is.

"It’s time to kill the web"
https://blog.plan99.net/its-ti...

Yes, having a whole page reload from each click is very inefficient. Does HTML5 provide a way to avoid reloading a whole page, but without using Javascript?

Yes, malware is a terrible problem today: if someone wants to hack an organization, pretty much the most guaranteed path to success is to use Web based attacks, by hacking sites that staff of the organization visit. Read this article - it is very worth your time, I promise: https://blog.plan99.net/its-ti.... If you are impatient, skip down to the section "Web apps are impossible to secure".

Yes, I have wondered if OSes are going to move to containerization for apps, which would provide that level of protection for the average user who does not know how to run a browser in a VM. There is a product for Windows called Bromium that uses virtualization to sandbox web pages. I think some of the browsers do that to but I don't think they use virtualization - not sure. There is an interesting blog post about how hard it is to write secure web apps: https://blog.plan99.net/its-ti...

"tin foil hat" - ROTFLOL. Good to know about being able to provide for non-JS folks - thanks for the info - I am a server side guy so I don't know the Web frameworks like react except at a basic level. About the "tin foil hat" thing though - most people don't realize how vulnerable Javascript makes them. Those who do realize it are not "tin foil hats" - they are prudent. Here's a good article on this: https://blog.plan99.net/its-ti...

It's rare to encounter if you only install software from your distribution, because typically, people will hack around it or simply force everything to compile against the same version of the library. I documented this problem a few years ago: here's a relevant GCC bug and if you want a slightly easier to read explanation read this doc I wrote on writing shared libraries and search for "scoping".

The long and short of it is that in ELF, every symbol exported by a shared library (including internal symbols if you aren't careful!) exists in a global scope. Imagine you have a function called "clear()" defined in your program. Not so unlikely, right? Now imagine that you link against libfoo.so.1, which in turns uses libncurses to implement some of its functionality. Well, now you have a problem. It turns out that the ncurses API dates from before the time when prefixing function names with the library name was common in UNIX, and it also defines a function called clear. In any sane operating system (like Windows - gasp) this is not a problem. Your program doesn't use ncurses directly, so there's no conflict there. And libfoo is not linked "backwards" against your program either. So when libfoo invokes clear(), control should be transferred to libncurses.

However, that's not what happens. What actually happens is that libfoo jumps into your program and then crashes with stack corruption, because clear() was defined there first. The fact that libfoos ELF headers state that it depends on libncurses will cause ncurses to be loaded into memory, but not actually used for this function.

To put it mildly, this is not what most developers expect. The example above may seem contrived, but a far more common case is when a program indirectly uses two versions of the same library. This is what happens when you use mozilla.org provided Firefox binaries. Then, Firefox from upstream is compiled against libstdc++.so.5, because it's more widely available. Firefox loads some plugin .... for instance maybe it loads SCIM if you want to type Chinese as part of the GTK+ input methods framework .... which in turn loads something else written in C++ .... which in turn loads libstdc++.so.6 - well, now you lose, because you have the same library defining symbols with different names. The OS has sufficient information to pick the right one, but doesn't, because of the general way in which binary loading on Linux works.

For the specific case of libstdc++ this is "fixed" by using symbol versions which are basically a gross hack ... they make the risk of name collisions less likely but do not eliminate them. Except that it wasn't actually fixed, as that bug describes. This is a general problem that affects all libraries on ELF based platforms.

One small problem is that ruby is not copy-on-write friendly, forked processes dirty up pages and lose the memory savings, there's a bunch of posts over at: http://izumi.plan99.net/blog/ explaining the issue, he also has a few patched to ruby to fix this. I don't know if YARV or Rubinius are going to fix this in release versions in the future.

Minix 3 has a BSD style license so it does not preclude looking and using the source. Versions released prior to 2000 were under a more restrictive license (personal copying only, no redistribution with your changes already merged in, non-commercial use and so on).

I would not consider Singularity to be under an Open Source license myself though. It is more in the vain of pre-2000 Minix (educational/academic use). However the technology in it is interesting and Google's Mike Hearn has a good series of blog entires giving an overview of the ideas within Singularity.

I agree. I've had correspondence with Zed in the past: I was asking him some questions about Rails's support for process forking (I was working on improving Ruby/Rails copy-on-write support), because as the Mongrel author he probably knows some gotchas. What I got in return was a series of very offensive emails. I did my best to stay polite, but every single email I got back seemed to be full of hate and rantings about Rails and Ruby.

No doubt that the guy's brilliant, but I wouldn't want someone like him as my colleague/employee/business partner/etc.

"Holy. Crap. You're not the guy that writes Active Record, are you?"

If you're referring to DHH, then no, I'm not him. My stance isn't as extreme as his ("database is just a big hash") but I do agree with some of his points. Transactions = good. Foreign key constraints = good. Stored procedures = only use when absolutely necessary. Normalization = weight between pros and cons in application code complexity and data redundancies. Etc.

"The thing a lot of OSS developers seem to forget is that many applications are primarily for data processing with user interfaces thrown on top. I.e. Not every damn "web app" is a blog or wiki, where it's primary purpose is to be a web app."

Not every, but *a lot* of them are. Very often they're systems for displaying, storing and retrieving small to moderate amount of information (unless you're working on a really really big multi-million system).

"Fact is that, if Rails wants greater acceptance (and, yes, I realize it is already widely accepted -- I'm talking about continued growth), then it's going to need to support things like composite keys. Why? Because people use them, and the application may have come years before the web interface."

I don't think so. I'm pretty sure that people complain about composite primary keys because it's so easy to complain about. Most of them probably wouldn't consider using Rails even if it fixes all its "flaws". *
There was a time when I took all Internet complaints very seriously. I worked very, very, very hard to meet peoples' demand, and I did it for free. In the end, it didn't help. Whenever I publish a fix for one complaint, they complain about other things. It's an endless cycle. The complainers can never be satisfied no matter what I do.
For example, people complain about memory usage in Rails. I've developed a way to reduce the memory usage by 30%, and look - very few people are interested! The people interested in my work are extremely disproportional to the number of people complaining.

* But by fixing Rails "flaws", you've just made it worse. The reason why Rails is so great in the first place is because it's a very specialized framework. It's not trying to be the thing for everything, like J2EE. If you make it the thing for everything it'll be a lot more painful to work with. It's like saying that your television can't wash your clothes. While it's possible to make a television that does that, it would be a royal pain to make and to work with.

I hate to spoil your fun, but SCIM does exactly what you describe. As proof, look at the following screenshots. First I type "ni". It brings up this list: screenshot
The most likely word that I want is the word that means "you", which is indeed the first character shown on the list.

Suppose that I don't want any of the characters on the first page, so I go to the second page by pressing 'Page Down': screenshot
If I select the first character on page 2, and I type "ni" again, then it will show up on the first page: screenshot

Now, are what more 'criticisms' against SCIM do you still have?

I hate to spoil your fun, but SCIM does exactly what you describe. As proof, look at the following screenshots. First I type "ni". It brings up this list: screenshot
The most likely word that I want is the word that means "you", which is indeed the first character shown on the list.

Suppose that I don't want any of the characters on the first page, so I go to the second page by pressing 'Page Down': screenshot
If I select the first character on page 2, and I type "ni" again, then it will show up on the first page: screenshot

Now, are what more 'criticisms' against SCIM do you still have?

I hate to spoil your fun, but SCIM does exactly what you describe. As proof, look at the following screenshots. First I type "ni". It brings up this list: screenshot
The most likely word that I want is the word that means "you", which is indeed the first character shown on the list.

Suppose that I don't want any of the characters on the first page, so I go to the second page by pressing 'Page Down': screenshot
If I select the first character on page 2, and I type "ni" again, then it will show up on the first page: screenshot

Now, are what more 'criticisms' against SCIM do you still have?

Eh? SCIM works perfectly on Firefox here. It works in Thunderbird as well. In fact, it works in all GTK, Qt, Mozilla-based apps and in OpenOffice (which is pretty much 99.9% of all apps on a modern Linux desktop). Not sure what you mean by "input is terrible" or "predictive text". If you "predictive text" you mean a dropdown box in which all possible characters are shown, then I can assure you: it is there.

My did *is* typing Chinese because we *are* Chinese. My dad is typing Chinese *all the time*. I have used the standard Chinese input method in Windows as well, and I notice no difference in functionality. We aren't "suffering". If you don't believe me, look at these screenshots in which I'm typing Chinese in Skype and Firefox:
Skype
Firefox
OpenOffice

Which version of SCIM and Fedora are you using? This is SCIM 1.4.4. Actually I haven't had problems with SCIM since version 0.6.

Eh? SCIM works perfectly on Firefox here. It works in Thunderbird as well. In fact, it works in all GTK, Qt, Mozilla-based apps and in OpenOffice (which is pretty much 99.9% of all apps on a modern Linux desktop). Not sure what you mean by "input is terrible" or "predictive text". If you "predictive text" you mean a dropdown box in which all possible characters are shown, then I can assure you: it is there.

My did *is* typing Chinese because we *are* Chinese. My dad is typing Chinese *all the time*. I have used the standard Chinese input method in Windows as well, and I notice no difference in functionality. We aren't "suffering". If you don't believe me, look at these screenshots in which I'm typing Chinese in Skype and Firefox:
Skype
Firefox
OpenOffice

Which version of SCIM and Fedora are you using? This is SCIM 1.4.4. Actually I haven't had problems with SCIM since version 0.6.

Eh? SCIM works perfectly on Firefox here. It works in Thunderbird as well. In fact, it works in all GTK, Qt, Mozilla-based apps and in OpenOffice (which is pretty much 99.9% of all apps on a modern Linux desktop). Not sure what you mean by "input is terrible" or "predictive text". If you "predictive text" you mean a dropdown box in which all possible characters are shown, then I can assure you: it is there.

My did *is* typing Chinese because we *are* Chinese. My dad is typing Chinese *all the time*. I have used the standard Chinese input method in Windows as well, and I notice no difference in functionality. We aren't "suffering". If you don't believe me, look at these screenshots in which I'm typing Chinese in Skype and Firefox:
Skype
Firefox
OpenOffice

Which version of SCIM and Fedora are you using? This is SCIM 1.4.4. Actually I haven't had problems with SCIM since version 0.6.

Follow-up to my last comment.

I do notice a problem in pressure sensitivity compared to Krita and Photoshop. Take a look at this image that I just drew with my tablet. If you look at the red lines (and particularly the areas pointed to by the blue arrows), you'll see that the transition in brush width is not smooth. In my pressure sensitivity options, 'hardness' and 'size' are turned on. Turning on 'opacity' does not seem to help.
For comparison, this is how a line looks like in Krita, and it looks much smoother.

This may be a thing that one wants to improve.

Follow-up to my last comment.

I do notice a problem in pressure sensitivity compared to Krita and Photoshop. Take a look at this image that I just drew with my tablet. If you look at the red lines (and particularly the areas pointed to by the blue arrows), you'll see that the transition in brush width is not smooth. In my pressure sensitivity options, 'hardness' and 'size' are turned on. Turning on 'opacity' does not seem to help.
For comparison, this is how a line looks like in Krita, and it looks much smoother.

This may be a thing that one wants to improve.

Good point wrt copy on write. The most common methods of deploying rails (with mongrel_cluster) do not use fork() but I just found this article on doing so if anyone's interested in it. http://izumi.plan99.net/blog/?p=19

I would like to say for the record, that I didn't say that FastCGI ran apps inside apache, I don't know where you got that from.

I've been following this project for a while (meta-blog here. Aside from the innovative hardware (especially with the screen and mesh network), I've been intrigued with the bizarre GUI, called Sugar (review of HIG here. It's a freaky interface that goes way beyond the traditional desktop metaphor where you run "applications" and save things in "files".

Best of all, soon kids in 3rd world countries will be able to annoy the crap out of their parents with funky casio beats.

• Whirlpool library for Ruby. This is written by me, based on the sample C implementation by the inventors.
• The above library can also be used in C apps. Just copy whirlpool-*.[ch] to your project. See whirlpool-algorithm.h for API.
• The GNU Crypto library for Java contains a Whirlpool implementation.

So you mean that the distribution should decide which modules/classes it should omit?

That could cripple the standard platform of Java modules developers can depend on. It could cause worst-case scenario's like this one, quoting:

Debian has packaged Wine in a way different to upstream, and this can cause extremely subtle bugs. One incident that sticks in my mind is where I wasted an entire Sunday afternoon and evening working with a user to track down why a program was crashing when they selected a menu item. It turned out that when the program started it was querying a registry key that didn't exist, and squirreling away a NULL pointer in some internal data structure. And when it tried to access that key it crashed. Why was the key missing? Because the installer invoked the regedit.exe program to merge a pre-written .reg file into the registry, which is more convenient than using the registry apis. No error checking of course because on Windows this cannot fail. And why was regedit.exe missing? Because Debian decided it looked like a "utility" and as such should be in an optional package

"There is a name for those people who visit your site while using IE. They are called your customers. You sounds as if you do not care about your customers."

I care about my customers and users, and that's why I use level 2, and not level 3. Actually I use a variation of their code: my version displays the box with a half transparent gray shadow that covers the entire page. When the user clicks on 'Continue' it'll disappear without having to reload the page, and it won't come back for 3 days (that's the cookie timeout). And while I won't use it on my commercial sites, I will use it on my high-traffic non-commercial sites.

And those users and customers would benefit too if I spent the time I wasted on tweaking for IE on doing useful work.

"Some people don't use Firefox because they already have IE and it works."

The point is IE doesn't work - as I said, broken PNG alpha channel support and broken 'em' unit support, among other things. I'm not forcing everybody to use Firefox, I'm strongly urging my visitors to not use IE.

"- no "Stop" button on the toolbar"

What are you talking about?

"-a mandatory search control toolbar - the kind of "browser helper" thing people have been told contain spyware (anyone remember "Gator"?). (if they wanted a Google, Yahoo or other search toolbar, they would have downloaded and installed one)"

Where do you see people ever complaining about search toolbars? I've seen enough average users who installed Yahoo/MSN/Google toolbars and they don't even realize it, let alone complain about it.

Anyway that's not the point. Then don't use Firefox. Then use Opera, or K-Meleon, or whatever. As long as it's not IE.

"http://home.nc.rr.com/emulroy/programg.htm"

I just tried it out in Firefox and IE. Other than the space difference between the left and right column, I don't see any other difference. But neither look correct. I don't know how it's supposed to look like.

"Many use IE so know it works. They normally prefer to not fix what they feel is not broken. If your web site is one of the rare ones that does not work with IE, they are more likely to decide the site is broken than that to download and use some other browser."

Tell the same thing to the people who create IE-only sites.

"and not some "Microsoft is the evil empire with all that money and we socialists object to that" type of drivel."

How about "it's safer and features like tabbed browsing makes life easier"? That's exactly what the Firefox box already says.

Now it turns out I was wrong, there HAS been a problem with J2ME in the past, there was a bug in the bytecode verifier (written in C/C++ ....) which allowed a malicious Java program to take control of the phone. But the issue for the attacker is, once you are running on the chip - now what? The guy who found this vulnerability (which I would hope is fixed in new phones!!) said it took him 4 months to reverse engineer the OS on his Nokia phone. And that's just for one model of one phone. Good luck making that sort of hack spread quickly.

The basic point is that Java itself (which is all most phones allow) is safe. The parts of a phone that aren't safe are the parts written in C or C++ or assembly: for instance, BlueTooth stacks, the JVM itself, maybe parts of the OS can be attacked by creating gui elements with really long names or something. But the basic scheme is secure (unlike on desktop machines), and the attack surface is much smaller than full computers. And even if you do somehow manage to hack a phone via its unsafe parts, the diversity in the market acts as a protection against epidemics.

I haven't seen any compelling evidence that Linux or MacOS X are more secure than Windows is against the twin threats of malicious software and badly trained users. They're all based on similar security ideas, which just don't cut the mustard. A better security model does exist, but it's not implemented in any desktop operating system today.

Now, J2ME is a flawed platform in many ways, but in terms of security they're light-years ahead of where desktop computing is. There are many things we could learn from it.

However binary distribution of C++ apps impossible? Give me a break. You speak as if upgrading the core components of a system are a daily tasks for the user. We have packages for that and the distribution compiles the code and makes a binary package for the distribution!!! See, thats easy. If you're favorite software has been updated then wait for your disitribution to update it. No different than having to wait for Office 2009! Same thing.

However binary distribution of C++ apps impossible? Give me a break. You speak as if upgrading the core components of a system are a daily tasks for the user. We have packages for that and the distribution compiles the code and makes a binary package for the distribution!!! See, thats easy. If you're favorite software has been updated then wait for your disitribution to update it. No different than having to wait for Office 2009! Same thing.

However binary distribution of C++ apps impossible? Give me a break. You speak as if upgrading the core components of a system are a daily tasks for the user. We have packages for that and the distribution compiles the code and makes a binary package for the distribution!!! See, thats easy. If you're favorite software has been updated then wait for your disitribution to update it. No different than having to wait for Office 2009! Same thing.

BWAHAHA! Try to tell that to the developers of the preferred Linux desktop environment, KDE, which is entirely written in C++. And I'm not even mentioning such non-working programs as Firefox and Inkscape.

BWAHAHA! Try to tell that to the developers of the preferred Linux desktop environment, KDE, which is entirely written in C++. And I'm not even mentioning such non-working programs as Firefox and Inkscape.

BWAHAHA! Try to tell that to the developers of the preferred Linux desktop environment, KDE, which is entirely written in C++. And I'm not even mentioning such non-working programs as Firefox and Inkscape.

C++ support: it does work. No, a single binary MAY NOT WORK. *Unless* you also distribute the needed libraries. Nothing AT ALL is preventing you from doing that

I guess I should have elaborated, go read this section of the page and then read the ELF section as well. If you understand what's written there you'll see the problem - the lack of a stable C++ ABI is not fatal in and of itself, though it does cause major pain, but combined with the lack of predictable symbol scoping it means it's impossible to reason about the interactions between a binary (any binary, even a C based one) and the rest of the operating system.

For instance, if a game written in C++ loads a private copy of libSDL (C), then it may crash because libSDL may dlopen libaRts (C++) for audio in KDE, and STL inlines in libaRts will collide with the equivalent inlines in the game itself despite libstdc++.so symbol versioning. That'll probably cause a crash or hang.

This is a "do not pass go" type problem. It means any program, no matter how bug-free or what language it's written in, can potentially crash in undebuggable ways in certain legal system configurations. It's broken by design and the relevant people either ignore the problem or don't see fixing it as a priority.

Other implementations are, of course, possible. How is the digital data protected after it is decrypted?

I was thinking of something like the Windows Secure Audio Path. The problem with your SSL scheme is that the program which renders the audio/video can be trivially turned into a decryptor just by redirecting audio output to a file. Now you can do this with Windows XP too but it requires running the OS under a virtualizer like VMware (but not VMware as IIRC the drivers for that aren't signed for SAP compliance) which emulates commodity hardware with SAP signed drivers. Setting one of these up is a bit of a pain and most users won't be able to do so.

For your Ashlee Simpsons and the like maybe somebody somewhere will do so and put it up on P2P for some reason, but for more obscure stuff this sort of thing can make it very hard to find (and anti-virtualisation code in Windows/hardware itself could seal that off too), which would make the analog hole the only way forward. And realistically not many people bother with that either.

• Driver API. Centralised driver development doesn't work - period. Assume the existance of a totally awesome vendor who is happy to release GPLd drivers with their new widget. They put a penguin on the side of the box. They immediately get their ass sued off by people who buy the widget, plug it into Goobuntu or whatever, nothing happens and for some reason they aren't satisfied by the explanation of "Well it'll Just Work in 12 months when the driver has been accepted upstream, been merged with your distros kernel patches, and you upgrade your OS". They want it to work now damnit, and Windows/MacOS can do this so why can't Linux?

• More driver stupidity. Not every program people run on Linux is GPLd today, and nobody tries to force them to be so. It's obvious to many people involved with Free software that the victories come when developers see why open sourcing their work is beneficial and choose to do it of their own free will, not when their arms are twisted into it. Yet the kernel developers do exactly this for drivers, and threaten (or actually do) sue random vendors who distribute binary drivers (except not nVidia, as that'd cause mass civil war). Worse, the kernel developers are getting more militant not less. This is simply not a tenable situation for desktops which deal with far wider variety of hardware than servers. In its current state Linux can never be a desktop kernel, unless you redefine "desktop" so far it loses all meaning.

• C++ support. It doesn't work. It's unbelievably slow, the glibc developers refuse patches to fix it, and is only reliable as long as you use "pure" binaries built with the same compiler that everything else is. This makes robust binary distribution of C++ apps impossible and as nearly every large desktop app is written in C++ this is a problem. Just try distributing a C++ application on Linux without getting all N^2 distros involved or requiring the user to know what a compiler is. Hell, try distributing any application at all without getting distros involved. And for all kinds of reasons centralized software distribution is a big usability and political nono.

• No easy install/uninstall - if you're comfortable with partitioning etc then you can get Fedora installed without too much bother, but Ubuntu doesn't even have a graphical installer, and as far as I'm aware no distro today offers an easy way to remove it and put Windows back to 100% disk usage. Who in their right mind would try a program that ate 10gigs of disk space and didn't come with a way to uninstall it?

• No credible DRM support. Every major company that deals with media uses it, Microsoft and Apple support it and Linux sucks at it. This effectively freezes Linux out from the upcoming world of legal online media (music/video stores etc).

I could go on ... unfortunately there's a general attitude of "who cares" in the community with regards to most of these issues so they aren't getting fixed or even talked about. Without these fundamental things I don't see how Linux can ever be a credible general purpose consumer desktop OS. The best you might get is a closed-box, unupgradable "console" type machine. But I wouldn't class that as a competitor to Windows or the Mac.

"So autopackage will stomp all over the files installed by the distribution by default."

"Great to know. (What happens if it installs a version of a library that is ABI incompatible with a version that the distribution ships?)"

"Surprisingly, people in autopackage's target demographic probably would complain about autoconf..."

"But regardless, the question was how will autopackage deal with an ABI conflict (lets say the gcc-3.3->gcc-3.4 one) between itself and a library it wants to dynamically link with at runtime."

"What you focus on isn't the point; the issue was that dealing with the above will (most likely) require you to deal with a whole host of things which are decidedly not "desktop applications.""

"So autopackage will stomp all over the files installed by the distribution by default."

"Great to know. (What happens if it installs a version of a library that is ABI incompatible with a version that the distribution ships?)"

"Surprisingly, people in autopackage's target demographic probably would complain about autoconf..."

"But regardless, the question was how will autopackage deal with an ABI conflict (lets say the gcc-3.3->gcc-3.4 one) between itself and a library it wants to dynamically link with at runtime."

"What you focus on isn't the point; the issue was that dealing with the above will (most likely) require you to deal with a whole host of things which are decidedly not "desktop applications.""

"So autopackage will stomp all over the files installed by the distribution by default."

"Great to know. (What happens if it installs a version of a library that is ABI incompatible with a version that the distribution ships?)"

"Surprisingly, people in autopackage's target demographic probably would complain about autoconf..."

"But regardless, the question was how will autopackage deal with an ABI conflict (lets say the gcc-3.3->gcc-3.4 one) between itself and a library it wants to dynamically link with at runtime."

"What you focus on isn't the point; the issue was that dealing with the above will (most likely) require you to deal with a whole host of things which are decidedly not "desktop applications.""