Posts by Liam Proven 145 posts • joined 7 Jan 2008
Pidgin still works fine. Yahoo IM is long dead, though, along with AOL AIM and MSN.
But ICQ still works! https://icq.com/
Pidgin also works rather well with Telegram, which for me is a big win, as Pidgin takes about 1% of the RAM of any of those abhorrent Electron-based clients. This puts Telegram ahead of Signal, Whatsapp, Viber, Slack, or any of their kin.
There's one difference, AFAIK.
In /The Restaurant at the End of the Universe/, a child calls Arthur "a jerk, a complete arsehole". (It's a callback to Wowbagger the Infinitely Prolonged.)
In the US edition, this was changed to "a jerk, a complete knee-biter"... such a splendidly irrelevant and contrived epithet that some in the fan club adopted it forthwith.
LXDE was all right, and did the important stuff, but it was less customisable -- or harder to customise, life's too short to find out which.
E.g. I want the Windows key to open my app menu, and Ctrl-Alt-T for a terminal. Xfce makes those easy. I couldn't work out how to do them on LXDE.
But it's irrelevant now, because LXDE is dead. LXQt has replaced it and LXQt sadly is not finished yet and misses functionality I find important, like changing my wi-fi credentials from inside the GUI.
But neither LXDE nor LXQt is significantly lighter than XFCE. Whereas all of them use about ½-⅓ of the memory of say GNOME, the LX?? desktops use maybe 10% less RAM than XFCE. That, IMHO, is not worth worrying about.
A desktop that does everything I want, is quicker, and uses half the RAM? I'll have that. One that saves a further 50MB of my 16GB but doesn't do stuff I want? Not worth it.
If you read my earlier articles on containers, they discuss FreeBSD Jails and Solaris Zones in detail.
But neither FreeBSD or Solaris has anything like Clear Containers, and LXD is trying to do stuff that even Solaris never attempted.
Those technologies were the specific focus of this article: LXD and Clear Containers, their resemblances and differences. Not containers in general, which I've been covering for the Reg for 6-7 years now. Including AIX WPARs and other implementations, yes, right back to CP/CMS.
Docker on Mac OS X and Windows runs a VM containing a minimal copy of Alpine Linux -- then your containers are started under that.
There are also Windows Server Containers, which contain Windows sessions, but can be managed with Docker commands and scripts -- but they can only contain Windows binaries. They're not compatible with Docker Linux containers.
I stand by it.
Look at VMware ESXi: a circa 350MB download, and when running, it takes 1.8GB or so of RAM before you start the first VM.
That is *not* "bare metal." That's an OS in its own right. Furthermore, it's running a Bash shell, optionally SSH, a TCP/IP stack, USB device support -- even today, I'm willing to bet there's most of a Linux distro in there somewhere.
A dedicated hypervisor OS is not the same thing as -- for example -- IBM p Series virtualisation, where the hypervisor is right in the firmware.
ESXi and Hyper-V are basically cut-down full-stack general-purpose OSes, pared back so that there's just enough to start and juggle VMs and not much else. Management is offloaded to client machines.
That's not the same thing as the in-firmware, OS-less hypervisors of the non-x86 vendors -- IBM's LPARs and PRISM, Sun/Oracle SPARC LDOMs, etc.
Comparable, yes, but not the same thing.
The 386 could only support multiple virtual _8086_ sessions: that's why it was called "virtual 86 mode". You couldn't virtualise and run 386 (or 286) code in multiple sessions on the 386 -- only plain old real-mode DOS, as on the original 8088/8086 PC.
So, something different. VMware etc. let you run multiple x86-32 or x86-64 environments on an x86-32 or x86-64 machine: the *same OS* can be host or guest or both.
By the way: QEMM didn't do multitasking or virtualisation. You needed DESQview for that.
Slightly surprised there was no mention of the Geneve 9640, a 3rd-party replacement motherboard that could be installed in the Peripheral Expansion Box to make it into a stand-alone computer. It delivered most of the improvements of the stillborn TI 99/8 and more, realising the potential of the TI.
It was a very impressive upgrade and shows what TI could have done with the machine if it had stuck with it.
http://www.mainbyte.com/ti99/geneve/geneve.html
http://www.old-computers.com/museum/computer.asp?c=1208&st=1
The first draft of the article did mention the pyboard, but I asked the editor to add the C.H.I.P. as it seemed more relevant. To keep it short, it replaced the link to the pyboard.
The article is not about programming languages. It is about operating systems. Thus, it doesn't matter what compiler is hosted on top of Linux, that does not address the issue that Linux is a problem, as it is too large, too complex, too slow, too cryptic and too difficult to be a good educational tool.
(RISC OS, meanwhile, is better than that on all fronts, but it's hopelessly obsolete.)
Sheesh, people. You lot couldn't have failed any more heroically to NOT GET IT.
[1] I was not promoting the Oberon SBC.
I was not even promoting the Oberon OS itself.
What I was saying is this:
As we now have effectively-free super-simple hardware, we now need free, super-simple software to go with it.
I am not proposing that Oberon is this software. It was merely a convenient example, since this little device just recently shipped (and sold out).
The culture of computing for several decades has been C and Unix or Unix-like OSes. Oberon shows that an essentially one-man language, compiler and OS can produce a real, viable, practical, usable OS that an entire University department ran on for decades.
The IT industry assumes that operating systems have to be written in C to work -- wrong -- and must by nature be big and complex -- wrong.
I'm not saying it should be Oberon. It should not be Oberon. Oberon is obsolete.
But it should be something simple, clean, modern, written in a single language from the bottom of the OS stack to the top -- and that language should not be C or any relative or derivative of C, because C is old, outmoded and there are better tools: easier, safer, more powerful, more capable.
We should start over, using the lessons we have learned. We should give kids something small, fast, simple, clean, efficient. Not piles of kludge layered on top of a late-1960s hack.
No, we should not be teaching children with "real world" tools. That is for job training. Education is not job training, and vice versa. You don't teach schoolkids woodwork with chainsaws and 100m tall trees. You don't teach chemistry in an oil refinery. You use little safe educational tools.
Secondarily:
[2] Oberon is not Pascal.
You lot evolved from ape-like hominids. (Clearly not very far, in some cases.) That doesn't mean you are still apes. You're human now. (FSVO 'human'.)
Pascal evolved into Modula-2, which evolved into Oberon, Oberon 2, Oberon-V, Oberon-07, Active Oberon, Zonnon and so on.
Oberon the OS evolved into AOS, then into Bluebottle, then into A2.
[3] Oberon the language and Oberon the operating system are not the same.
No, there is no Oberon OS for the Pi. Yes, there are compilers for Oberon the language for ARM and for the Pi. Using them, someone could port the OS, sure. It has not been done, partly because, as I said, it's an effectively obsolete set of tools that has been long superseded.
You know there _was_ a version of LocoScript for the PC.
https://en.wikipedia.org/wiki/LocoScript
You could run that on 32-bit Windows, or under XP Mode on Windows 7. No idea where you'd legally get a copy now, though. The company hung on for a long time, but I think it's dead now. There's a mirror of the homepage here:
http://www.locomotive.com/locopcw.htm
Another company, SD Microsystems, serviced the aftermarket for decades, but I think they've gone too.
The point being, important lessons were learned building the Unix shell. Yes there's cruft too -- it's over 40 years old. But it's polished smooth, for all that.
PowerShell learns few of those lessons.
George Santayana said: "Those who do not remember the past are condemned to repeat it."
Henry Spencer modified this to: "Those who do not understand Unix are condemned to reinvent it, poorly."
Microsoft is still learning to reinvent Unix -- slowly separating text-mode core OS from graphical layer; learning the importance of a rich command line; learning to write graphical commands that emit said CLI, easing automation. But it's not doing it terribly well.
The trouble is that the Stockholm Syndrome world of corporate IT has been brainwashed into believing that it's the only way and to frantically deny the Great Heresy that is Unix.
[...] Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river.
This is not the place to try to explain why each of the above directories exists, and what is contained in it. At first it all seems obscure; worse, it seems deliberately obscure. When I started using Linux I was accustomed to being able to create directories wherever I wanted and to give them whatever names struck my fancy. Under Unix you are free to do that, of course (you are free to do anything) but as you gain experience with the system you come to understand that the directories listed above were created for the best of reasons and that your life will be much easier if you follow along (within /home, by the way, you have pretty much unlimited freedom).
After this kind of thing has happened several hundred or thousand times, the hacker understands why Unix is the way it is, and agrees that it wouldn't be the same any other way. It is this sort of acculturation that gives Unix hackers their confidence in the system, and the attitude of calm, unshakable, annoying superiority captured in the Dilbert cartoon. Windows 95 and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic.
What made old epics like Gilgamesh so powerful and so long-lived was that they were living bodies of narrative that many people knew by heart, and told over and over again--making their own personal embellishments whenever it struck their fancy. The bad embellishments were shouted down, the good ones picked up by others, polished, improved, and, over time, incorporated into the story. Likewise, Unix is known, loved, and understood by so many hackers that it can be re-created from scratch whenever someone needs it. This is very difficult to understand for people who are accustomed to thinking of OSes as things that absolutely have to be bought.
http://steve-parker.org/articles/others/stephenson/oral.shtml
Not Good Enough, VMware. 2/10, must try harder.
It's 2015. Virtualisation is free now. There are a choice of both proprietary freeware & FOSS hypervisors & management tools. VMware still has a stranglehold on the high end, sure, but MICROS~1 is working hard to attack that, whereas the FOSS crowd have caught on to what I was writing about on the Reg in 2010 and are starting to develop better, more mature tools than VMware's 1960s-style whole-system-emulation approach.
And still, the independent emperor of whole-system virtualisation requires Windows clients? My leg, it is being pulled.
It is long long past time. I can understand Hyper-V Server requiring a current version of Windows to manage it -- I mean, MS has to sell licences to live -- but a /rival/ to MICROS~1 requiring a MICROS~1 product to use the rival's? That is *insane*.
Even Microsoft itself produce a free client for Terminal Server & give it away, for nothing, for both old versions of Windows and for Mac OS X -- and the protocol is well-enough described that there is a choice of FOSS clients for Free OSes; choose your desktop, there's a client.
In essence, the VMware client is not massively more complicated. The logic of machine creation & management is just a few dialogue boxes. Even implementing stuff like remote mounting of disk images, or upload/download of VM images, is nothing complicated. All the hard work of the fancy inter-host clustering and migration is done by the hypervisor; the client just has to provide a UI to the raw command line or whatever it is.
There should be a cross-platform client served up right into your browser -- any browser -- when you connect to the host, rendered in modern dynamic HTML or, at a push, in Java. And a binary client available for the leading 2 commercial OSes and enough code or docs for the FOSS people to implement one too.
Having 3 clients for Windows, crappy as they apparently are, which don't even support all extant versions of the host, means the company is just not trying.
This isn't awesome or epic; it's sad, a failure.
PowerPC might have had a chance. As it is, the last vestige in the GP computing market is the Amiga X1000, as discussed here:
http://www.theregister.co.uk/2010/06/21/amiga_x1000/
Uses a PWRficient PA6T-1682M, made by, ironically, a subdivision of Apple.
Talk about things going in circles...
Oh, yes, Apple-only... except for a few minority platforms. So tiny you probably never heard of them. Let me see, there was...
• the Playstation 3 from an obscure little Japanese company called Sony.
• the Wii and WiiU from another unheard-of Japanese outfit, Nintendo
• oh, and the xBox 360... who was that, ah, yes, Microsoft.
80 million units of the first, 100 million of the second, 80 million of the third. Over a quarter of a billion PowerPC CPUs shipped in those 3 alone.
But they're not desktop computers, so you ignore them.
That's ignoring embedded systems etc.
Tell me again how that means Apple-only, would you?
Good for you.
I woudn't. Why? Because currently I have 52GB of Dropbox and 15GB of Google Drive, without paying a penny.
And I suspect that few others would, either.
Ubuntu does Linux OSes. It should not have been mucking around with cloud services, music stores etc. when there are others that do those things far, far better. It is foolish to enter a crowded marketplace with strong, established players unless you have a remarkably compelling offering, which Ubuntu didn't.
The LBA limit was an early 1990s thing.
The BIOS hard disk handling was by cylinders, heads and sectors-per-track (CHS). Various revisions and vendors limited these to different numbers, but effectively, the limits were something like 1024 cylinders, 16 heads and 63 sectors per track, meaning a max disk size of 504MB.
Changing from CHS addressing to LBA allowed more - depending on implementation, either 4GiB or 8GiB. 8GiB was the limit for a while - e.g. the 1st 2 generations of G3 Macs could only boot off the first 8GB of a hard disk, because of early EIDE controllers.
No, the DOS limits were /much/ earlier and older.
From old old memory:
MS-DOS 1.x didn't support hard disks.
MS-DOS 2.x did, but just one, of up to 10MB.
MS-DOS 3.0 supported a single hard disk partition (per drive) of up to 32MB.
MS-DOS 3.2 supported two partitions per drive, so 2 x 32MB.
MS-DOS 3.3 supported one primary and an extended partition containing as many 32MB "logical drives" as you wanted. (I built an MS-DOS fileserver with a 330MB hard disk ones - it had drive letters C:, D:. E:, F:. G:, H:, I:, J:, K: and a leftover 11MB L: drive. Messy as hell but all you could do without 3rd party "disk extenders" such as Golden Bow's one. The server OS was 3Com 3+Share if anyone rememembers that.)
Lots of vendors implemented hacks and extensions to allow bigger disks, but they were all mutually incompatible and many failed to work with some 3rd party software. Of course, anything that directly accessed disk data structures, like a defragger or a disk-repair tool such as Norton Utilities was 100% guaranteed to catastrophically corrupt any such extended disk setup.
The one that caught on was Compaq DOS 3.31. It used an extension of FAT16 that allowed bigger clusters - still just 65,535 of them, but multiple 512 byte sectors per cluster, permitting bigger partitions. The max cluster size was 16KiB so the max disk size was 65535*16KiB = 2GiB.
This is the one that IBM adopted into MS-DOS 4 and it became the standard. However, disks over 512MB used inefficient 8KiB clusters - i.e. files were allocated with a granularity of 8KiB and even a 1 byte file took 8KiB. An 8.0001KiB file would take 16KiB.
This became disastrous over 1GiB where the granularity was 16KiB. Roughly 20-30% of disk space would be wasted because of this granularity as inaccessible "slack space".
This was only fixed in Windows 95 OSR2 with FAT32, which permitted huge disks - up to 2TiB - with much finer granularity.
But all of DOS 4, 5 and 6.x permitted disk partitions of up to 2GiB.
http://xkcd.com/612/
The point being, there is disagreement over how fast it's going, partly over the maths, partly because of incomplete models, partly because we don't know all the factors yet.
But that doesn't mean it /isn't/ happening, and it is extremely foolish to think "hey, some estimates say no problem, so we're FIIIIIIIIIIIINE!"
Jeez, so much disinformation in the comments.
It is *nothing* to do with drivers for Intel GMA9x0 graphics; that's a side-effect. There are in fact 64-bit drivers for GMA950:
http://www.insanelymac.com/forum/topic/280675-partial-fix-intel-gma950-for-os-x-108/
The first-gen Macintels had Core Solo & Core Duo CPUs. These were 32-bit-only chips. These Macs can only run up to Snow Leopard, which includes both 32-bit and 64-bit kernels.
Ref: Apple cheat-sheet - http://support.apple.com/kb/ht3696
The 2nd gen had Core 2 Duo, which can run 64-bit code, but the EFI firmware is still 32-bit.
Ref: http://macs.about.com/od/macoperatingsystems/qt/Minimum-Requirements-For-Os-X-Mountain-Lion.htm
Lion includes both 64-bit and 32-bit kernels and thus can run on machines with 32-bit firmware, so long as they have at least 2GB of RAM. (32-bit Macs have the same limits on RAM above 3-and-a-bit gig as 32-bit PCs.)
Ref: Apple support again - http://support.apple.com/kb/ht4287
Mountain Lion & Mavericks only have 64-bit kernels. They therefore require machines with 64-bit EFI to boot at all.
http://reviews.cnet.com/8301-13727_7-57387846-263/will-your-mac-run-mountain-lion/
However, as the above article states, the higher requirements of GPU capabilities in the newer OS's versions of OpenGL, OpenCL etc. do mean that some models whose CPU and EFI are compliant will not work.
> Nothing against Ubuntu, but you'd be lacking in senses if you decided to pick Ubuntu over CentOS
> for your server needs after this news.
I disagree. A lot of sysadmins rate Debian as considerably better than RH. Many still prefer APT-GET over YUM and RPM, or Debian's openness over RH's lack of it.
Ubuntu Server is basically Debian with a fixed, regular release schedule and a cleaner install, minus TASKSEL, which those rolling their own don't need anyway. I know some sysadmins who prefer Ubuntu Server to Debian for this reason: /nothing/ is installed by default, not even ssh. 3rd party support for Ubuntu is also now more plentiful than for Debian or Red Hat.
> I thought that RHEL was free to obtain and run but you paid for a support contract?
No. RHEL is purely commercial and is only available by buying it.
CentOS & Scientific Linux take RHEL's published source files & recompile them. Their OSes are Free and freeware: no charge, no support.
Oracle takes the sources, recompiles them, gives the binaries away for nothing but charges for support, as you describe.
Oracle is thus offering RH's own product for free & charging less for support. Various commentators, myself included, speculated that this was in an effort to reduce RH's share price for possible hostile acquisition. However, this hasn't happened. Possible reasons are:
• Perhaps people don't think Oracle can support someone else's code as well as the code's authors can.
• Perhaps people just don't trust Oracle.
This is true, yes, but I did specifically say:
> Then you need to licence the [...] layered products on top, such as Exchange or SQL Server.
> Of course, various bundles and deals apply to all this.
Those layered products include the high-end management tools.
It's a complicated, hairy mess, as many Microsoft resellers said to me in my background research.
That is true of /all/ forms of virtualisation, though. If you're running dozens of Windows or Linux or whatever instances on top of a single copy of Windows Server with Hyper-V and that host copy of Windows goes down, all your instances are gone, instant toast.
OS virtualisation makes no difference to this at all.
Of course, this is what clustering and failover are for, but then again, if Windows integrated some form of containers, there is no reason at all that they could not fail over to containers on other hosts.
Nope, IBM VM is something quite different again - this is using one OS kernel to multitask multiple instances of another, different OS kernel, one per user. This is directly homologous to, say, running multiple Windows Server instances on VMware, or running multiple Linux instances on top of Hyper-V Server.
Again, do buy the ebook. :-) I'm not on royalties here! It's just the best intro to the basic underpinnings that I could do.
No, timesharing is something quite different. May I suggest my Reg ebook?
http://www.amazon.co.uk/Brief-History-Virtualisation-Liam-Proven-ebook/dp/B006MSECAS
The source articles are still on the Reg if you search for them.
Timesharing means simultaneously multitasking multiple interactive user sessions; it's something totally different.
No problem - but they've changed their tune, then. My source was the Microsoft speakers at _Microsoft's launch event for WS2012_ which I covered here:
http://www.theregister.co.uk/2012/11/01/windows_server_2012_technical_launch_day_overview/
... and here:
http://www.theregister.co.uk/2012/11/02/windows_server_2012_what_is_new/
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2020