Posts by rleigh

Raspberry Pi gains new FreeBSD distribution

Re: For those interested in servery type projects

ZFS also requires a 64-bit system, so I doubt it could be run on the Pi in any case. (In my experience--there is no ZFS on FreeBSD for 32-bit powerpc)

IPv4 addresses now EXHAUSTED in Latin America and the Caribbean

Re: ARIN not doing any favors

Anyone who cared could try this out for free anytime during the last 15 years. Myself, I originally signed up for a plain tunnel (but no /64) from (IIRC) BT back when they were running experimental IPv6 services. Around 13 years back, I switched to a /64 from sixxs.net and used it for a decade. That was totally free; you can set up a tunnel and then get /64s in addition. You do need to register with RIPE, but that's not overly onerous. There are several other providers, e.g. he.net, and there have been since the days of 6bone.

Today, I have native IPv6 from my ISP, so every device on the network gets an IPv4 NAT address and IPv6 global address with no user action required.

For Windows guest - KVM or XEN and which distro for host?

Data storage for shared systems

I've used Btrfs a fair amount as a Debian developer, in order to take advantage of some of its features such as snapshotting and RAID. It has some nice features, but to be completely realistic, it's not anywhere near ready for production use, and isn't likely to be for seveal years at least. I've had unrecoverable data loss and multiple kernel oopses/panics (though for experimental stuff, so not serious for me). You can't trust the RAID code; a SATA cable glitch made it toast both the transiently failing drive *and* the mirror, turning both in to unusable messes which panicked the kernel when you tried to mount them. Coupled with the lack of a usable fsck tool, it would be foolish in the extreme to trust this filesystem with important data. Depending upon the usage patterns, performance can also be awful, though it can be very good. Now, I use it intensively for snapshotted source build environments (schroot), but that's transient stuff I can recreate in minutes should it get blown away. It may become trustable with time, but at present I don't consider it anwhere near that. I think SUSE may regret making it the default; if their users want to be guinea pigs finding all the remaining bugs, good luck to them!

For Linux, there's the plain and boring ext4, or xfs, or zfs with the appropriate kernel patches. And others as well, but if reliability is the goal, one of those is a good choice.

One of the most annoying things I've found with both virtualisation and multiboot systems is data storage. You inevitably end up with data spread over multiple systems, duplicating stuff and also wasting tons of space due to disk partitioning and having neither system being able to safely/efficiently access each others' filesystems, especially when using VMs and they may be mounted already. My suggestion for this is to move all the user data off to another system. I got a small HP ProLiant microserver, and put FreeBSD10/ZFS on it. Now all the data is available to any system via NFSv4/CIFS, which works nicely for all of: single native OSes, dual-/multi-boot systems, and VMs. ZFS also eliminates inefficiencies of partitioning wasting space: all the data is in a big pool split into datasets (which can have quota/size limits). The choice of OS for this was really down to native ZFS support, including in the installer, and a desire for something new to play with. Debian GNU/kFreeBSD can also do this.

With the above setup I have EFI/GRUB2 booting of Debian GNU/Linux, Gentoo, Windows7 and BIOS booting of Debian GNU/kFreeBSD and FreeBSD10 on and amd64 system, and OpenFirmware boot of Debian GNU/Linux and FreeBSD10 on a powerpc system, all using the same user filesystems. There are also a fair number of kvm and VirtualBox images, all of which can also take advantage of the shared storage. The local storage can then be small: it's just the basic OS install and temporary scratch space.

Down with Unicode! Why 16 bits per character is a right pain in the ASCII

Re: Agreement

While the BOM shouldn't matter, in many places it does in practice. A couple of examples:

Shell scripts starting with #!/bin/sh (or perl, python, etc.). The presence of the BOM changes the starting bytes of the file, making the shebang non-functional. Every tool handling shebangs would need patching to cope with this variant.

Concatenation of files containing BOMs. This leaves you with BOMs spread throughout the data stream. You then need to make sure that every tool handling the data can filter out or ignore BOMs. You can't usually do that either since you might have non-UTF8 binary data in the stream and stripping them out after the fact would mangle the data.

For these and other reasons, the simplest and most reliable solution is to never ever put BOMs in UTF-8 data. Shame on Microsoft for saving UTF-8 text with BOMs by default...

Re: Bravo!

I hate to be a pedant (actually, that's a lie), but it's not strictly true that all control characters are below codepoint 128. There is the ECMA-35/ISO-2022 C1 control set designated at 128-159, mirroring the C0 control set with the high bit set. This is obviously incompatible with UTF-8 though, and so not available when you have UTF-8 designated with "ESC % G".

'SHUT THE F**K UP!' The moment Linus Torvalds ruined a dev's year

Re: ioctl

Deletion doesn't matter--the device is already open at this point, so unlinking the device node makes no difference. Most devices would prevent removal (e.g. module unloading) if in use, so this is an unlikely situation. But if it does occur and it disappears, you would probably get EBADF since the fd would no longer be valid. Not a situation I've ever seen though.

ioctl

The prototype for ioctl(2) is:

int ioctl(int d, int request, ...);

where 'd' is an open file descriptor. The error being returned was ENOENT (no such file or directory). Since ioctl only works on open files, an error saying it doesn't exist is clearly awry. It has to exist: you already opened it! The file descriptor can be invalid, but that's EBADF.

So Linus' criticism here is totally justifiable, since it's meaningless to return ENOENT in this context.

Regards,

Roger

Windows 8 hardware rules 'derail user-friendly Linux'

"As to the ARM stuff, in the abstract this is annoying. But in reality, I can't see the presence or absence of the ability to load linux onto win8 phones and tablets affecting me one way or the other."

ARM isn't restricted to "phones". There is also the matter of tablets, laptops, and potentially even desktops to consider. What about general purpose boards such as the Raspberry Pi, which are also ARM? It's a general CPU architecture, not a class of products. If the OEMs are forbidden to allow modification of the allowed keys, it will be impossible to boot anything except Microsoft-signed code on these systems, and that *is* certainly something that would affect people. It's a requirement for using the Windows logo on the hardware, which is a big commercial incentive to lock down the hardware, or else it has the appearance of not being approved for use with Windows, even when it's perfectly supported, which could have a commercial impact if it affects sales. Thus Microsoft achieves total lock-in on the platform.