Makes me wonder what for I'm running the infrastructure here...

[Tags: hubertf, ipv6, rants]

   ... idling ...
   ...
   <dork> http://www.blabla.com/
   <you> WTF?!
   ...
   ... idling ...  

Now here's an idea to fix this: The problem comes from the fact that people just cut the URL from their browser's address bar. Now, what if taking an address from the browser would not only take the URL, but some useful text, like the URL's title. Which is already loaded and displayed right now anyways, or which could probably be loaded when right-clicking on an URL and selecting "Copy Link Location" in Firefox. I.e. the idea is to have something like "bla bla bla - http://www.blabla.com/" copied, instead of just "http://www.blabla.com/":

   ... idling ...
   ...
   <dork> bla bla bla - http://www.blabla.com/
    * you is instantly enlightened!
   ...
   ... idling ...  

=> more meaning of URLs in chats, international understanding, peace on earth!

(If someone earns a lot of money from this idea, I'd like to get a share of it :-)

[Tags: hubertf, rants]

Doing some digging, it seems that

    \usepackage[pdftex]{graphicx} 

    \usepackage{graphicx} 

/home/cvs/src-current/obj.i386/tooldir/bin/nbinstallboot  -t raw  \
	-mi386  bootxx /home/cvs/src-current/obj.i386/destdir/usr/\
	mdec/bootxx_cd9660
nbinstallboot: Invalid magic in stage1 bootstrap 0 != 7886b6d1
nbinstallboot: Set bootstrap operation failed 

I've verified that daily releng builds work, so this was probably a problem on my side, but where? I didn't want to blindly rebuild the whole toolchain on this slow PC, so tried investigating. Comparing /usr/mdec/bootxx_cd990 from my own and the releng build showed that there *was* some difference, so I continued looking in src/sys/arch/i386/stand/bootxx/bootxx_cd9660 to see what the matter was. Using hexdump -C showed that there was a difference between my bootxx_cd9660 and the releng one, and after getting the intermediate files of the build (bootxx_cd9660.tmp, cdboot.o) from a helpful being on #NetBSD, nm(1) showed that my version of cdboot.o lacked several symbols, e.g. a "start1".

As the cdboot.o file is made directly from a cdboot.S file, there's probably not much chance for the compiler to break things, and I didn't really believe that the assembler would add symbols on its own. Asking other people, they confirmed that they had "start1" in their cdboot.S files, while my copy of the same file lacked such a symbol. From there it was just a quick look at src/sys/arch/i386/stand/cdboot/CVS/Entries to fine the problem:

miyu% cat CVS/Entries
/Makefile/1.6/Wed Jun 28 20:23:05 2006//
/cdboot.S/1.2/Mon Aug  7 23:24:18 2006//T1.2
D 

Next thing to do: cd src ; cvs up -A, just to be on the safe side.

[Tags: cvs, hubertf, rants]

Maybe NetBSD should add some holes to the operating system and at the same time start making money from selling anti-virus products, personals firewalls and whatnot... doh!

[Tags: hubertf, rants]

``Business is unpredictable and unsafe. The Internet is dangerous. Many blogs have been written about these dangers, and there's no way we can list them all here. Read the blogs. The Internet is covered in slippery slopes with loose, slippery and unpredictable footing. The RIAA can make matters worse. Patent trolls are everywhere. You may fall, be spammed or suffer a DOS attack. There are hidden viruses and worms. You could break your computer. There is wild code, which may be vicious, poisonous or carriers of dread malware. These include viruses and worms. E-mail can be poisonous as well. We don't do anything to protect you from any of this. We do not inspect, supervise or maintain the Internet, blogosphere, ISP's or other features, natural or otherwise.''

I think this should be brought to every user's attention before they get access to a computer. And re-acknowledged every day. Anyone care to provide stickers, also in translated forms? :)

[Tags: funny, hubertf, rants]

In the "cleaning up old mail" department, I have added a new entry to the FAQ telling people what FTP server's good (for those that don't use NetBSD yet :-), and I've added the people that made donations to the g4u donations page.

While talking about donations: don't assume I'm getting rich. Many donations are like $2 to $10, which is nice for some food'n'drinks, but it won't pay my rent or allow me to devote huge globs of time to this project. Unfortunately.

Let me point out one donation in that regard: I always find it interesting to see questions from companies on the g4u list, asking about hundreds of machines to clone, and the very latest hardware, but without ever donating a bit back (hint: a commercial license of a product similar to g4u is like $50, and now take that * the number of your machines to see what you're saving. Split that by two and send it to paypal@feyrer.de to give g4u a bright future!).

Anyways, with all those companies happily using g4u, I'd like to point out one donation that's very special to me: A kindergarten school donated $15 for g4u. Working in education myself, I have a rough impression of how much money they probably have (ie.: none), and this makes it a very, very nice donation to me. Thanks a lot!

[Tags: g4u, rants]

^- No, this is not NetBSD-related at all, but the website served me as source of personal amusement. The (assumed) fact that lawyers killing web forums and thus killing free speach SUCKS! I hope people will be able to stop this madness.

[Tags: hubertf, rants]

 bar=	@bar@ 

I was looking at various "modern" system startup mechanisms and -replacements, and came across Apple and Sun's FAM which (though different in detail) do not only add metadata in addition to boot scripts, but also use it to manage services that were handled "on demand" by inetd before.

Now, here's what NetBSD (to be on-topic) has in /etc/inetd.conf to run rshd(8) when a service request comes in:

 shell stream tcp nowait root /usr/libexec/rshd rshd -L 

 service shell
 {
 	disable         = yes
 	socket_type     = stream
 	wait            = no
 	user            = root
 	server          = /usr/libexec/rshd
 	groups          = yes
 	flags           = REUSE
 } 

Now here's what Apple's "launchd" takes for the same thing:

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
 "http://www.apple.
 com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
 <dict>
 	<key>Disabled</key>
 	<true/>
 	<key>Label</key>
 	<string>com.apple.rshd</string>
 	<key>ProgramArguments</key>
 	<array>
 		<string>/usr/libexec/rshd</string>
 	</array>
 	<key>inetdCompatibility</key>
 	<dict>
 		<key>Wait</key>
 		<false/>
 	</dict>
 	<key>InitGroups</key>
 	<true/>
 	<key>Sockets</key>
 	<dict>
 		<key>Listeners</key>
 		<dict>
 			<key>SockServiceName</key>
 			<string>shell</string>
 		</dict>
 	</dict>
 </dict>
 </plist>
      

One extra bonus to Sun (which also put the startup item metadata into XML files): They don't keep the various services' data in files in a directory as Apple seems to do, but to install a service, you read it into a SQL (SQLite, actually) database, which is then used upon system boot.

Seems the times of readable(!) ASCII config files are ending. While thinking for a long time that Solaris is one of the better things since sliced bread, their new start up system in Solaris 10 made me turn away.

--

References: "Getting started with launchd", Solaris' svc.startd(8) and smf(5).

[Tags: hubertf, rants, rc.d]

Of course things look even more different in the userland, I guess, with NetBSD's crosscompiling framework for userland and X...

[Tags: portability, rants]

Let's hope for a better day tomorrow...

Update: Thanks to the people who've mailed and encouraged me. To answer the question what happened, let's say there are different opinions about the value of precompiled binary packages, esp. in light of security problem. While the practice so far was/is to just rm them (and thus make the set of binary pkgs on the FTP server inconsistent and mostly unusable w/o compiling missing things from pkgsrc), it may happen that this handled a bit more user/functionality-oriented. To what extend the binaries will be moved around and how this will be documented, or if the binaries may even be replaced by non-vulnerable packages remains to be seen.

While pkgsrc is all fine for building by compiling, the situation with availability of binary packages for slow platforms is very suboptimal. Having started pkgsrc in 1997, with Al Crooks, and with the goal to provide precompiled packages for slow machines -- I used to maintain an archive of binary packages for NetBSD/amiga before that time -- I can't really say that this goal was met today, 8 years later. The blame to not put enough emphasis on crosscompiling and esp. "management" processes to ensure better availability of binary pkgs on all platforms supported by NetBSD goes to myself in this case. Shoot me. :)

[Tags: hubertf, rants]

• ``As the old saying goes, FreeBSD is about performance, NetBSD is about platform portability, and OpenBSD is about security. So is that still the case?''

  I don't think so, and it probably never was, as I hope for FreeBSD (and OpenBSD too): Each of the BSD projects has more than one goal, and at least for NetBSD, establishing state of the art security is just a natural thing that needs no special emphasis. Likewise, if performance deficiencies are found, the past has shown that they do get addressed. As such, asserting that each of the BSDs has only one goal in mind seems a short-sighted to me, and leads to wrong impressions in the reader that e.g. performance and security are of no concern in NetBSD. Which is wrong. Of course NetBSD is performant, and of course it is secure - we just emphasize something else as our major feature.

  Speaking from a historic perspective, when UCB stopped BSD, FreeBSD and NetBSD emerged (with some detour via 386BSD). With 4.4BSD supporting a wide range of hardware platforms, FreeBSD concentrated on the PC platform only, and NetBSD set the goal to provide a stable Unix(like) platform that behaves equally well on all platforms (as far as the platform allows). Seems NetBSD didn't have to re-adjust its goals so far...

• ``The NetBSD advocates are quick to claim that NetBSD 2.0 now beats FreeBSD in both performance and features. Fortunately, that is just not true.''

  There are a number of benchmarks out there that show differences to this statement. Not all of them, not in all details, but the statement in general is not true any more.

• ``There simply is not anything else in any other OS that is as flexible, easy to use, and full-featured as netgraph.''

  Uhu. While reading the description on what Netgraph is, I wonder: What about System V's STREAMS, which was there um... 20(?) years ago?

• ``Advanced network features and protocols such as SACK, NFSv4, SYN-cache/SYN-cookies, compressed TIME_WAIT, and accept filters allow for fast, secure, and scalable network operations in an ever-increasing hostile and busy Internet. Packet filters like IPFW and PF provide advanced filtering, shaping, and NAT sharing.''

  Um, just for the record, NetBSD has SACK too, SYN-cache etc. is available since NetBSD 1.3(?), a collection of packet filters (IPF, PF) and traffic shaping. I'm not sure what the other features listed mean, so I cannot comment. (Someone please update the NetBSD list of features please!)

• ``Outstanding desktop and laptop support is provided by a number of technologies.''

  Um, like the PCMCIA framework that I hear is based on NetBSD's code? Given it's goal of portability, NetBSD was long made to support a lot of devices, even in a "removable" way, and thus getting drivers working esp. on non-Intel, 64-bit machines helped a lot.

  I agree that interfacing with some vendors like nVidia or groups like KDE and GNOME could be improved, but then KDE runs pretty well out of the box on my PC running NetBSD. :)

• ``The "Ports" collection provides one-step support for over 11,000 3rd party applications.''

  Yes, size does matter. :) I hear rumours that many of these "ports" are duplicates for difference in options and language, and that some do not build properly. To counter this with some number, from the ~5500 packages in pkgsrc, less then 100 (<2%) were broken in the last attempt to build them all. (Details)

• ``NetBSD 2.0 is a significant step forward for NetBSD, but the large amount of stagnation cannot be overlooked.''

  Hu?

• ``It's great that NetBSD is committed to supporting legacy architectures, but how does the effort to do so benefit modern architectures or encourage wider use and more adoption of NetBSD?''

  Portability is more than "supporting legacy architectures", as can be known. It's about making hardware abstractions, and establishing interfaces to easily replace support for code, like change of CPU or bus architecture. This lead to products like the ARM-based "keyboard-video-mouse" switch from Avocent, the PowerPC-based Brocade SAN switches of the Sony PSP TCP/IP stack, just to name a few. And it also serves as a base for FreeBSD's PCMCIA/Cardbus support, FreeBSD/alpha, FreeBSD's bus_space/bus_dma(?) support, I hear. :)

  (Details: various NetBSD-based products from HP, IBM and Sony, MacMini, Xen, products based on NetBSD)

  Maybe some more understanding of the issue and facts at hands should be gained before making more statements like the above.

• There's one statement in Robert Watson's (second) part of the article that I want to emphasize though (in favour of FreeBSD):

  ``This includes doing a better job with PR.''

  Yes please!!!

  I have promoted NetBSD at various joint BSD-boots at roadshows in Europe, and while NetBSD and OpenBSD were present, there were always people asking for FreeBSD which we had to send away. It would be really nice if some FreeBSD people could be found to do some on-site adovcacy at various events. Anyone interested feel free to contact me to coordinate joint BSD activities!

Last, I'm impressed that DaemonNews gave their good name to publish such a statement in such a position.

[Tags: Articles, rants]

The second entry is more annoying, as it's hurting NetBSD's reputation in a print magazine: The company GeNUA, producer of firewalls from Germany, was abandoning BSDi and looking at alternatives. In an interview in the german magazine "freeX" they describe how they choose OpenBSD. NetBSD was not chosen as the NetBSD developer group was considered too closed and to rarely pick up inspirations from outside, which makes it hard to integrate it into release planing:

``Problematisch ist es dagegen fuer GeNUA, dass die NetBSD-Entwicklung von einer sehr geschlossenen Gruppe betrieben wird, die externen Anregungen nur selten aufgreift. So ist es schwierig, zukuenftig benoetigte Features sicher in die Release-Planung einzubringen. Aus diesem Grund konnte GeNUA nicht auf NetBSD als Basis fuer die weitere Entwicklung von GeNUGate setzen.'' (FreeX 1/2005, Seite 8)

So:

1. GeNUA never contacted NetBSD directly (in contrast to what the article makes one think)
2. OpenBSD developers apparently never made it clear they were talking for someone else when they communicated with NetBSD
3. Given personal experience and history of relation between NetBSD and OpenBSD, I'd be surprised if the contact was made in a constructive manner. (I have no further details here, so just a guess)