From: jrodman
Date: 17:09 on 16 Jan 2007
Subject: BSD "Slices" on x86 (and amd64)
I know we have some BSD coots out in the audience, so in advance, I'm
going to say that I don't want to hear any defenses for this complete
and utter crap, because that's what it is. Of course I welcome parallel
hate for comparable things.
The various forks of the BSD operating system all use their own
partition scheme, but to enable "compatability" they stuff their
partition scheme inside one of the partitions in the PC MS-DOS partition
scheme.
Now, the MS-DOS, CP/M partition schcme sure is lousy. Four partitions
isn't enough, and extended/logical terminology is clunky, and the
linked-list-on-disk business is a ball of hair. But it's the partition
scheme which is used on x86 systems. If the box will only ever run one
operating system, fine, you can opt to lay the disk out any way you
please, but if you're going to bother to make it possible from different
systems to understand the disk, you should implement the same format!
The BSD "slice" are not cute, and they are in every way inferior to the
awful MS-DOS partitioning. They are more limited in number, they are
not comprehensible by other toools, and they introduce a needless second
level of hiararchy in order to access partitions that confers no
benefits and incurs complexity. Moreover, each of these systems has its
own slightly different, slightly incompatable variation of "slice", so
that they cannot be shared (here again you see the lack of comprehension
of interoperability), and to boot they insist on using names to refer to
things defined by the platform which are inconsistent with the platform
(cf. slice vs partition vs slice).
The least one could do is the bare minimum of allowing these "slices" to
be stored in "dos logical drives" or "logical partitions" in more modern
x86 parlance, and still be bootable. NetBSD has managed this amazing
feat of engineering. FreeBSD and OpenBSD have apaprently yet to figure
it out. DragonFly BSD can do it, but yet the installer still refuses
to let you set things up this way. Great.
The upshot of all this stupidity is that I do not believe I can actually
install the various flavors of Unix I had intended to test with on this
new machine at the same time. The common solutions to this problem I
see are:
1 - Use VMWare and friends - which is basically another way of saying
*don't* install them. Especialy if you wanted to get real-world
performance data
2 - Buy more hard disks
3 - Use one of these "nifty" bootloaders that actually changes the
partition table on the fly during boot to give you more fake
partitions
The very existence of 3 is something I had not imagined possible until I
started looking into this, but yet it seems to be a common
recommendation on certain mailing lists. What a horrific concept.
I guess I was misled when I was told that the FreeBSD port was mature!
Interoperability. You'd think UNIX developers would have heard about
it.
-josh
From: jrodman
Date: 16:52 on 28 Dec 2006
Subject: apt, and proxies (Debian again)
I use a cacheing web proxy to make my life suck a tiny bit less. I use
it in my browser, and I export it as an environment variable. This
works well. All kinds of tools get accelerated.
( Well, really I export it as two environment variables, HTTP_PROXY and
http_proxy, because it seems people were various kinds of stupid at
various times. Oh well. )
Now, apt (a package tool), from debian supports http proxies. Handy,
since apt sometimes loses its mind and I have to manually delete its
package cache to force it to download them again. So it can regain its
mind faster.
Unfortunately, apt does not support http cacheing properly. It cannot
arrange to reliably discover when tiles provided by the standard package
repositories have changed. The result is apt-get update (find out
about new packages) often acquires a patchwork of mismatched old and new
files.
This causes it to complains about md5sums not matching.
Ye olde apt-get update hate: when `apt-get update' fails, it suggests
to fix this by running `apt-get update'. This invariably produces the
same error in a slightly different configuration. I wish all software
was so helpful:
"An error has occurred.
To fix this, please do exactly what you just did again."
Net result, `apt-get update' fails around 50% of the time (who knows
what the factors are). I would prefer it to work 100% of the time.
Since its support for caching proxies is broken, I would like to ask it
not to use a cacheing proxy. Looking at the configfile documentation:
blah blah blah all about proxy settings for http written in confusing
language... Then clarity:
The http_proxy environment variable will override all settings.
When there is a conflict between program-specific settings, and a
program-general setting, ignore the program-specific settings. Right.
Okay, so I cannot configure apt not to screw up. I have to remove the
environment variable before invoking apt-get. Well, how will I do this?
apt-get is indirectly invoked by various tools, so making my own
shellscript to run it is not going to work. I could replace apt-get
with a shellscript that invokes apt-get after removing the environment
variable, but this will be transparently re-broken on upgrade.
I guess I will simply have to manually remove both environment variables
before launching whatever tool that might invoke apt-get. And then put
them back.
-josh
From: jrodman Date: 04:00 on 17 Oct 2006 Subject: GTK, KDE, GNOME, etc and standard error So, in the land of UNIX, there exists three normal channels from the outside world to a program: standard in, standard out, and standard error. Standard in is where a program can expect to recieve keystrokes. Standard out is where a program can send its normal output. Standard error is where a program can send messages about unusual conditions and situations. In this simplistic but effective system it is possible to run programs, feed them input, see the output, and seperately find out about problems along the way. Modern toolkit authors seem to be suffering from some kind of cargo cult mentality. They noticed that a datastream existed for finding out about unusual conditions, and decided that this data channel is actually a good place to put any and all possible messages relating to potential problems which may not even exist or matter. Thus, in a modern KDE or GTK/GNOME application, standard error no longer actually represents errors. It in fact is full of status of lunched subdaemons, errors parsing some tree of mime types 8 libraries away from your application, warnings about slightly incorrect type declarions, complaints about buttons that are slightly the wrong size, and so on. The best part of all this spew is that if your program actually _does_ encounter something that you would need to know about "programname: error opening your_letter.doc: permission denied", it is buried in pages of spew, and you'll never see it. Even better is that of course the x console is totally useless. There is no way you would ever see an error produced by the X system itself, because any directly launched gui bits are all spewing in parallel to the same stderr inherited by the X server. So after suffering with this idiocy for many years, I decided to file a clear and cogent request for the GTK developers to address the issue. http://bugzilla.gnome.org/show_bug.cgi?id=362749 The response of course was, to paraphrase: Well, these messages indicate a buggy program, therefore our action is correct. So, to dissect this reducto-ad-absurdism style. If glib notices the program is running has a bug, it should detonate a nuclear warhead in downtown Manhattan. After all, once it is clear you are dealing with a buggy program, there is no need to actually consider whether your response is reasonable, helpful, or useful, it is self-justified because it is a response to a bug! Q. E. D.
From: Joshua Rodman
Date: 01:02 on 11 Sep 2006
Subject: Debian and the GFDL and stupid packaging decisions
Debian has decided that documents under the GFDL with so-called
"invariant sections" are non-free. This means that these documents have
sections which are you not legally allowed to modify. In a sense this
practice enables users of GFDL documents to refuse to pass freedoms on
to sub-licensees. One could imagine a practical scenario where such
documents become successively hidebound and unusable. Ironically, it
seems to go against some of the GNU ideology of freedom.
I think the GNU folks have sort made a mockery of themselves with this,
but I don't care that much. However, Debian has a policy of shipping
only free as in freedom components, and has decided that they should
remove this non-free documentation from their distribution.
The result:
jrodman@Skonnos:~ >man gcc
man: warning: /usr/share/man/man1/gcc.1.gz is a dangling symlink
No manual entry for gcc
See 'man 7 undocumented' for help when manual pages are not
available.
This is pretty impressive. Not only do I not get the documentation, I
don't get any sort of reasonable result. I don't even get an error that
the manpage is missing. What I get is a _missing symlink_.
jrodman@Skonnos:~ >ls -l /usr/share/man/man1/gcc.1.gz
lrwxrwxrwx [...] /usr/share/man/man1/gcc.1.gz -> gcc-4.1.1.gz
jrodman@Skonnos:~ >ls /usr/share/man/man1/gcc-4.1.1.gz
ls: /usr/share/man/man1/gcc-4.1.1.gz: No such file or directory
You'd think this means I forgot to install something, but that would
rely on the people packaging this stuff not screwing up. So there's
some kind of pointer to the currently installed version of gcc which
gets set up. I guess it picked the best option, eh? I mean it's not
like the documentation for gcc is available in some other form:
jrodman@Skonnos:~ >ls /usr/share/man/man1/gcc-*
/usr/share/man/man1/gcc-3.3.1.gz /usr/share/man/man1/gcc-4.0.1.gz
Oh, I guess I'm wrong: there's completely reasonable documentation
sitting right there. But hey, it's not like I'd want to read any of
those documents. What I really want is a glaring error, which makes it
seem like my system is misconfigured. And hey, I suppose it _is_
misconfigured, by Debian.
Just to be clear, Debian does manage to make things like Adobe Acrobat
and Macromedia (Adobe) Flash available via reasonable channels. They go
into a repository of packages called "non-free". I suppose completely
proprietary software systems with lock-in capability are more touchable
than slightly problematic licenses for the standard free software
compiler.
Great priorities!
(Yes I understand this situation may be temporary, but it's been this
way for a couple months now. Great way to leave your users completely
in the lurch! Oh that's right, if you're not running stable, you dont'
exist.)
From: jrodman
Date: 02:07 on 13 Aug 2006
Subject: A simple hate for livejournal
Nothing impressive here, but, all the same:
I was writing my grand opus explaining to an interested non-unix user
all the hateful things about GNU Texinfo, the lack of manpages, botched
Debian manpages, incorrectly installed Debian Texinfo pages, idiocies of
the info tool, and so on, in response to a question he asked about my
post to this list. It was pretty good.
(Okay, I didn't say _all_ hateful things about those topics, but I
covered about 12 different awful things in there.)
While working on the text, adding subheadings, providing links and
references, and so forth, I would repeatedly use the provided
[Preview this post]
button, and livejournal would dutifully render the post according to its
html limitations, and so forth, allowing me to determine that the html I
was hand-entering was at least close to correct.
Only after previewing the post a good fourteen or so times, cleaning it
up iteratively, and after I went to post it, did it let me know,
helpfully.
"Sorry, LiveJournal comments have a limit of 4300 characters, your 8934
character post that we've been previewing for you without complaint for
the last 15 minutes will have to now be manually chopped into pieces by
you and a text editor and copy and paste."
Thanks.
-josh
(Oh, and before you point it out, yes, I know I'm asking for it by using
LiveJournal, but I'm also asking for it by using the web, and by using
a computer at all. Ever.)
From: Joshua Rodman
Date: 21:26 on 18 Jun 2006
Subject: More info hate.
Trying to use expr, the argument 5.0 is not recognized as numeric, so I
wonder what is supposed to work. The man page doesn't say, the --help
doesn't say (nor -? nor -h).
so:
info expr
[...]
SEE ALSO
The full documentation for expr is maintained as a Texinfo manual.
If the info and expr programs are properly installed at your site,
the command
info expr
should give you access to the complete manual.
I suppose this text is technically correct.
The second part of this hate is unfortunately too tangled for me to
deduce. The short form is that Debian is hateful, and either the
package installation method, or the texinfo scripts, or the dpkg
install-info program or well, maybe something else is broken. And has
been so since before the year 2001.
Extra joy comes from the developers involved being so tired of the
situation that they don't bother to consitently comment/modify/clarify
bugs filed against the relevant packages, so a significant portion of
the hints in the bug tracking system are wrong.. Maybe it will work
correctly in another decade or so.
-josh
Generated at 10:27 on 16 Apr 2008 by mariachi