Slashdot Mirror

Is Linux a steaming pile of unreliable shit? No it isn't. Is Windows? Which one do you think has a large QA/QC department assigned to it?

Why, yes it is!

The core parts of Windows don't behave like that. You can drive Solaris into hard swapping that lasts for hours and it will come back just fine. But Linux? Write to a memmap()'d file under even moderate memory pressure and the core OS shits the bed performance-wise.

I need to reboot my Linux-based Android phone more often than I had to reboot old Win95 systems.

It's that exact kind of unreliability in corner conditions that make large-scale Linux systems less reliable then Solaris or even Windows systems - as long as you can get past the crappy third-party drives and fight through all the GUI-based cruft you'll find in Windows in order to just use the core of the OS kernel.

You need higher standards.

SSD vendors have some history of lying about sync writes being finished when they're actually still going on. Even Intel's early drives got that wrong, wasn't until their 3rd generation (320/710 series) that things worked correctly. Anyone burned by SSD deployments in that era, or by more recent drives that still don't worry about power loss protection, runs their own tests. To be safe here, you have to assume the drives are not being honest about sync writes.

RAID cards like that Adaptec only work if the individual write disk caches are disabled. I publish guides on how to setup all of the caches involved in that sort of system correctly, and you have to pay attention to that on the Adaptec models; just haven't published that guide yet. On many cards disabling the drive write cache is the default, safe setting.

The problem here is that SSDs require their write cache, both to meet their published longevity and performance specs. Disabling the cache makes them much slower and very short lived. Accordingly, SSD manufacturers don't even support disabling the cache in some cases. Intel's early drives had that problem, and it meant database corruption. They sorted the problem out on drives with power loss protection starting with the 320 series, and the models since have been fine. Not sure if you can turn the write cache off on them, but with the power loss protection you never need to.

All regular drives fail this sort of test. However, if you turn their write caches off, they then pass. So that's how people deploy them for "enterprise" use--with the disk write cache disabled. Add a battery-backed RAID cache for durable write caching when needed. I even publish guides on how to setup all of the caches involved in such a setup correctly.

The problem here is that SSDs require their write cache, both to meet their published longevity and performance specs. Disabling the cache makes them much slower and very short lived. Accordingly, SSD manufacturers don't even support disabling the cache in some cases. Intel's early drives had that problem, and it meant database corruption. They sorted the problem out on drives with power loss protection, starting with the 320 series, and the models since have been fine. Not sure if you can turn the write cache off on them, but with solid power loss protection you never need to.

And finally I have tried to profile a Python app for memory usage, but gave up when I discovered that Python doesn't even try to be efficient with memory usage. No point trying to optimise the main app when the runtime makes memory inefficiency pervasive.

It isn't correct that Python does not attempt to be efficient with its memory usage. You mentioned before that you had heard of PyMalloc. What is PyMalloc for? "Pymalloc, a specialized object allocator written by Vladimir Marangozov, was a feature added to Python 2.1. Pymalloc is intended to be faster than the system malloc() and to have less memory overhead for allocation patterns typical of Python programs."

You also complained about a limitation of PyMalloc wherein it won't free memory from its working set on the basis that it will probably need it again later. This will no longer be true as of Python 2.5 which is currently in beta testing: http://evanjones.ca/python-memory-part3.html

I feel that while we don't need IPv6 yet, waiting until we do need it would be foolish. Think of this in the same terms as the Y2K issue, which never became an issue because people took proactive action.

Some useful IPv6 related links:
    - http://www.simphalempin.com/dev/miredo/
    - http://evanjones.ca/macosx-ipv6.html
    - http://www.bieringer.de/linux/IPv6/
    - http://www.hexago.com/
    - https://addons.mozilla.org/firefox/590/ - displays ipv6 address in firefox, if it has one
    - http://www.ipv6.org/impl/windows.html

All that is really needed is for the pockets of IPv6 networks to join up, rather than staying as pockets. Maybe an IPv6 based P2P or something of the sorts might help provide some sort of momentum.

Mac OSX has had great IPv6 for a while (10.2)

http://evanjones.ca/macosx-ipv6.html

And the feds moved back their deadline so many times that even 2008 will be pushed back.

Apple even had a demo of ipv6 in OS9 once, and a long while back was big on it.

Most people, who enjoy semi-anon IP addresses from defacto forced reissue taht I know are against IPv6 and see it for all its regretful faults, despite its wonderful goals and alleged benefits.

In an IPv6 world... there will be no more anononymity except at a WiFi cafe lacking video cameras.

As pointed out by a previous post, there is a mirror available. However, if you really want, you can use this torrent instead. The video is actually pretty interesting, particularly if you are interested in search or distributed systems.

I'm a big fan of Python. I used it almost exclusively before taking my current job. But let's be honest, Python and Java just aren't intended for the same type of applications.

Python's standard library just doesn't have the breadth of Java's. For small apps, the CPython VM is lighter than Sun's JVM, but CPython's VM is lacking several capabilities that I'd consider pretty essential -- chief among them is the ability to return unused memory back to the OS. And for many tasks, CPython is still effectively single-threaded due to its global interpreter lock. Java has never suffered from either of these problems. These aren't trivial issues or the result of nitpicking -- they're rather severe limits (which make me seriously question the suitably of Python for enterprise apps, eg. Zope). Of course, once CPython does get decent threading, it's likely that it's GC subsystem will need to be totally rewritten. I apologize if it sounds like I'm beating up on Python. That's not my intent here. I love Python, and I only wish I could stop more people from using Perl :)

In fairness, it does look like the Python community is trying to address some of these problems. I just read a paper presented last week at PyCon 2005 on CPython's memory management. The author is developing some patches to let CPython return unused memory to the OS for most object types (except for Number, List and Dictionary). The memory manager still can't defragment its heap, so this isn't a perfect solution. As of a few weeks ago it looks like these patches haven't yet been accepted.

Both the addresses you specify have IPv4 addresses, and that is what your computer is using. To see how to set up a 6to4 tunnel follow this link. www.kame.net is the site to try to connect to for testing. Typing 'ping6 www.kame.net' give you something back, other than 'ping6: UDP connect: No route to host'.

At the moment I can't get it working, so I'm trying to see what I have done wrong.