Have you read this? Your satire seems inspired by postmodern literary critique. It also has the elements of a good BS "paper," and I'm guessing you picked this up at Columbia. This style is a large part of what got me through the common core courses.
This is what they would probably end with, as a workaround for poor legacy 32-bit architectures, like Intel x86 -- but only as a quick-and-dirty, temporary workaround. You can't have cleaner interface to a partition than seeing it as a continuous memory block. At least I can't imagine a cleaner interface, if you have any idea of such a thing, I'll be more than glad to hear it.
Do you realize how ridiculous your words are? "Legacy" 32-bit environments? Like the "legacy" 32-bit environment with the "legacy" operating system that you used to type into slashdot?
So it's cleaner to make the maximum filesystem size depend on the machine's pointer length than it is to simply write better software, even if writing better software means resorting to traditional ("legacy" as you might call it) methods?
The "single opcode MOV?" You do realize how mmap works? Certainly the user-level program can simply access it like memory, but this then goes through the VM (by means of a hardware interrupt on page fault) which calls some disk subsystem, which will eventually end up calling a disk driver. End result is that you write something to the disk. There is no magic MMU hardware which understands EIDE or SCSI and
maps memory to disk blocks - this is done through code. It's merely an abstraction to transfer the complex parts of the code into another layer of software, made necessary because of the poorly-thought-out layers of software.
How can a single MOV be considered "elegant" when you have to keep a data structure of which parts of the partition are mapped? Your single MOV instruction becomes a series of instructions to select a "view" of a partition, clean out old "views," and map new ones when needed. It won't be a MOV, it will be a function call into some library. How is this more clean than simply calling pread()? Of course, as you say, this is only a "temporary hack" - you can get rid of this once everyone is using 64-bit architectures.
It's not "clean" or "elegant" in any sense of the word. The mmap is a nasty hack because someone couldn't figure out how to use the same cache management that the VM uses in a user-level process. Someone simply chose a poor abstraction. It's a mistake, and I simply cannot understand how someone could let such a stunning error into any operating system.
I hate to spoil your naivete, but Intel and AMD don't give a damn about HURD, and they certainly don't design their hardware with this sort of thing in mind. Although the theoreticians don't like this, computer hardware is complex and non-orthoganal. If the HURD was designed to run on only 64-bit machines with clean MMUs, you'll be waiting a long time until HURD is stable on readily-available hardware. (Does HURD even support 64-bit architectures at this time? If not, then how can you possibly justify the mistake of having filesystem drivers use mmap?)
I don't give a damn about the politics. This is simply bad design. You can attack me with all sorts of accusations that I don't approve because of whatever politics, but this does not change the fact that someone made an immense error when designing the filesystem servers and certain people thought this error was "elegant."
I really didn't mean to flame you personally, but this is inexcusably bad design. I don't understand how someone can justify it, rather than admitting that it's a fundamental design problem.
I can appreciate that the filesystem driver is a userland process - this means I can write a "filesystem" as a normal userland process (eg, make some things have a filesystem-like interface, so you can do interesting things with databases like make/etc/passwd a directory). This is a cool idea.
However, using mmaping an entire partition is just crazy. This is poor design. What were they thinking?
Are they trying to avoid the system call overhead for seek() calls? This is the only reason I can think of that someone would do this - when you read/write/seek, you have to do a system call for seek(), but that comes "for free" when you mmap() because you specify the address. This would only be a problem with HURD-like systems, because there is no overhead if the filesystem driver runs in kernel space along with whatever other subsystems it needs to use.
I know everyone hates backseat designers, but I'd like to know if the following approach has been considered:
Make two new system calls, say "readaddr" and "writeaddr". These work like read and write, except that you also specify an offset (perhaps with a "whence" field like lseek). This saves you the overhead of calling seek all the time by combining the operations into one system call. This might be useful for other things as well, but I would imagine a filesystem driver is one speed-critical piece of code that does a lot of jumping around. Actually, I just remembered that there already are calls for this: pread/pwrite.
Another possible approach: using mmap is nice, but mapping in an entire partition is fubar. Why not map in specific parts of the partition as they become needed? Eg, keep superblock mapped right away from startup, and map in other parts as they are needed. Seems a bit complex, but could be done more easily with another layer of abstraction (some library which keeps a hash or something of mmap()ed bits and provides a nice interface for filesystem drivers). I'm guessing mmap was used as this transfers certain operations (eg, cache management) "deeper" into the "kernel" and avoids code duplication.
But anyway, mmaping an entire partition is really nuts. They're not getting any sympathy from me.
- specification of how you may and may not use your application layer. Count on Microsoft Outlook/Outlook Express as the only permitted email client. Do you think we have time to support your Linux system when 90% or more are happy with Outlook?
This is called "Delivery Status Notification" and has been a standard for some time now.
Before the Internet was big, I worked with proprietary (non-SMTP) inter-office mail systems. I remember one system in particular had this feature where it would display the status of a message to the message sender or administrator. A message would be marked "read" if the user lingered on the message for some configurable amount of time (remember, this was non-standard mail, so the vendor wrote both the client and the server).
I'm certain you can see the problems with this system: it's something of an invasion of privacy. Boss sends user a mail, user doesn't complete task in mail before lunch, boss confronts user, user claims he only had time to skim over the message, boss tells admin to pull out the logs.
Anyway, this can result in some pretty nasty situations, so I'm guessing the reason this hasn't been widely-implemented is because users actually don't want this (I just read through the standard and I can see a number of other technical problems which have possibly delayed its acceptance). I certainly don't want anything like this (even without that evil MUA behaviour described above, this sort of raises the bar for email, making it a "more serious" medium, and that changes the nature of what goes through email (consider what goes through email and why you would never receive a subpoena or summons through email)). If I had to complete every hair-brained idea sent to me through email from management, I would never get any work done. Without status notification, I can postpone this for a couple of days until I actually speak with the person involved and they've already forgot about the idea or we have a chance for a two-way conversation and I can convince them how bad their idea is.
I prefer keeping some anonymity on Slashdot (lets me rant more easily), but if you come across me on the Internet otherwise, you'll recognize me by my.sig, which is a three-line PostScript program (albeit not nearly as cool as the raytracer).
PostScript is an amazing language - completely changed the way I thought about programming. Bored with systems-level C programming? Give PostScript a try....
Excellent start. vi is the proper editor for these sessions.
The problem with Emacs? You're writing a lexer. You probably have a bunch of similar-looking statements for various keywords. Each statement is probably a little bit different, so cut-and-paste becomes tedious. Or, perhaps you have a table of thirty numbers in hex, which change using some complicated pattern.
Perhaps there's some way to automate this, so you can lay out some sort of table, and have Emacs generate code and automatically indent it? Of course Emacs can do that. Why, all you have to do is read in the first character using thing-at-point, convert it to an integer and then use a bit of recursion...of course, this could be more generally useful, so you might as well add it to your.emacs - ah, but you forgot to call save-excursion, so it's not a very user-friendly function...
STOP! No Lisp programming. Must write lexer.
Warmth. I find if I'm at home and dont put a pair of socks on I curl up in my seat, not very efficent
No, no, no. Must keep it cold. When it's warm, it's too easy to fall asleep. The colder, the better. If the temperature bothers you, repeat after me: Cold is the mind-killer. I will allow cold to pass over me. Cold is the mind-killer.
Incremental backups. maybe a cron job, tar your files at least every hour, preferably every ten minutes.
One word: CVS:) Important for larger projects, critical for marathons. cvs diff can answer the eternal question of "WTF was I thinking?"
Dont be hungry. Start getting hungry? Order a pizza (online).
Again, too easy to fall asleep after eating. Warm with full belly = nap time.
My own suggestion? Lots of liquids. You can only consume so much caffeine before experiencing psychadelic effects, so you'll also need water, and lots of it. This is not a preventative measure, but is rather disaster recovery: if you do fall asleep, you won't sleep long before the call of nature, and when you get up, you'll feel so guilty about "lying down for a moment" that you'll write your best code.
Good luck with the project - I imagine you're probably at the parser at this point, so go get those S/R conflicts:)
yet MySQL seems to be the only free RDBMS anyone's ever heard of.
This is probably the reason. MySQL gets the press, so PHBs are OK with it. Postgres gets no press, so PHBs are wary of it.
I had a PHB that was wary of using a free database for some incredibly trivial web database. I explained to him how using Sybase was a bad idea since he would need a competent *nix admin perpetually in the department to do simple things like backups, and how MSSQL has a bad security record, etc. This particular app just needed to do a couple of joins from php - it didn't even need to open up the SQL server to the world, only running locally on the web server. I couldn't possibly legitimze paying something for the trivial project, but the PHBs somehow thought that if we bought an MSSQL license, we would be treated to red-carpet support directly from Microsoft developers.
You know what convinced him to give the go-ahead to MySQL? MacOS X ships with MySQL. That means it's a serious product, not some fly-by-night sourceforge/freshmeat project written by a college kid between classes. Doesn't matter if more people use Postgres for more serious things. All that matters is if there's a big name behind it. Same thing with FreeBSD - they all wanted only Linux before Apple started advertising that their stuff was based on FreeBSD 4.4.
That's how things work in Corporate America. Those making the technical decisions often aren't the ones with the technical knowlege.
Keeping all the state server-side is the most secure option, and the one least likely to break.
I've done a few things trying to keep state client-side in cookies - but it's proven too unreliable (in addition to people who don't accept cookies, you have to deal with browser bugs, clients whose clocks are not set correctly, and so on). I mostly just keep it server-side now, like you suggest. The only downside is that, well, you're keeping the state server-side. Even with a lot of traffic, this isn't really all that much overhead, however. I've also noted that for something this simple, using a database is actually faster than keeping the state in some file (at least with persistent database connections). But this in itself probably doesn't warrant having a database if the site doesn't need a database for anything else.
So, yeah, this is probably the best way, but it feels a little icky keeping this kind of state server-side when it could easily be offloaded onto the clients.
Another possibility I just thought of: on the main page, you generate your image links to look like this: image.php?code=2476DA8DA77FF349890ACB66"
where the "code" is a hash of the IP, a timestamp and some secret string. image.php can then check the hash to make sure it matches up, and you don't end up keeping anything server-side and it doesn't have any extra file or database overhead.
Anyway, lots of possiblities - no need to use referer.
Fine, shred the session cookies. You then won't be able to see the images.
The point of the session cookies was to ensure, with cryptographic confidence, that a user has seen your main page before allowing them access to your images. Referer headers can be faked, but not the session cookies I described (eg, you can inject them into a wget session, but only after you've actually seen that main page from that specific IP).
Anyway, this is irrelevant - both will do fine for controlling your outgoing bandwidth, and I'm not really concerned about the "privacy" issue (if there even is a privacy issue - read my original post carefully, and you'll see that I don't care whether or not someone logs my referer, but I do care when it breaks my browsing session or they try to stupid things with the header like redirecting away from the data that originally attracted me; I'm perfectly OK with anyone logging all the headers my browser sends (although this is asinine pubescent behaviour in the case of these blogs), because, after all, that's what I sent to them).
My point is that using the referer header breaks under certain conditions - when I open an image in a new window, or when I "save" an image - but the session cookies I describe don't break under the same conditions. It's about broken, stupid behaviour, not some nutcase "privacy" thing.
There are basically two categories of software that you may need to run to get your broadband going:
Software to register an account
PPPoE software
The first software would be run only the first time you get your broadband installed. It would go through the steps of creating an account with a username/password etc. and it may automatically create an email account for you. It would also probably change a few settings (email/DNS server and whatnot) and it may install a "branded" version of IE.
This software may also record your MAC address, which is not very nice (this would mean that the service is restricted to the machine with which you run the stupid little program).
This is, of course, some stupid Windows program, but you may actually need an account before being able to use the service.
Hint: sometimes this software is just a little wrapper that invokes IE as a COM object and simply displays web pages. I know that SBC does this. To see if that's the case, right-click in the program and see if you get IE's popup menu. You can then bookmark the page to figure out the URL and you can complete the registration from any web browser instead of using the software.
Any software used to initially register the service can of course be removed after registering the service.
The second class of software it might install is PPPoE software (PPP over ethernet). ISPs are increasingly using this to provide DSL and cable service. I don't like this one bit, and I still can't figure out what possible advantage running PPPoE would have at their end except that they may be able to use some older software designed primarily for PPP (eg, RADIUS, mrtg on the PPP server software, etc).
If your ISP uses PPPoE, you'll need PPPoE software, depending on what OS you run. I believe Windows XP comes with a built-in PPPoE client, I know MacOS X 10.2 does, and I know Windows 9x and MacOS 8-9 definitely do not come with PPPoE software. FreeBSD comes with its own PPPoE client, but Linux usually does not (for Linux, you may have to download "Roaring Penguin PPPoE" - hit google).
So, the procedure would be: have a Windows box handy when you get your broadband. Since the software might register your MAC, make sure the Windows box has the same MAC address as your eventual NAT box (eg, swap out the NICs if necessary). Install the software and then figure out what it does. You might be able to use the account-creation stuff without their software like I did, but it's probably no big deal to go through their stupid little wizard. Then you figure out what kind of network setup they're using (whether or not it's PPPoE), configure your NAT appropriately, and drop their software.
If you're new to this, you should know a couple other things: first, you'll want NAT if you have more than one machine. NAT allows you to put all your machines behind your NAT router and your provider only "sees" your NAT box (I'm aware of how ISPs can attempt to detect NAT and how "stealth NAT" can defeat that, so there's no need to go into that here). FreeBSD makes an excellent NAT server that can run on really old hardware (you'll of course need two NICs, but there's no hardware requirements other than that) - the FreeBSD handbook has a section especially on this, and setting up NAT involves simply editing a few lines in/etc/rc.conf (and you'll probably want to install a DHCP server on the inside side of your NAT, and that's only a port install away). It litteraly takes two minutes to set up a FreeBSD NAT box from a default FreeBSD install. There are also several Linux floppy-based distributions that are designed specifically to run NAT.
The second thing you should know is that some ISPs discourage running servers by make your DHCP-assigned IP "very dynamic" (eg, it changes every few days no matter what). If you still want to be able to ssh into your box, you could use something like dyndns.org, or you could simply write a little script that "publishes" your IP on a web site or something whenever your IP changes.
Didn't mean to attack you personally. You were just a convenient target for a rant.
How many people even know how to point a telnet seesion - and are they even in your web site's intended audience?
I believe this kind of reasoning is a bit dangerous - it's very difficult to gauge your audience. You can, of course, gauge your intended audience, but you're always going to get some people in there that don't fit the demographic.
Example: a couple of years ago I wrote a bit of technical documentation for a system we were using internally in my department. I also linked it in from a couple of places, but I didn't restrict it to our local network since it wasn't any kind of secret.
I was quite surprised at some of the responses I got from that page. I, of course, didn't log referers, but I occasionally received mail from random people who found the site via a search engine. One mail was from a guy in India who needed some help with a technical problem and he found our site, and another mail was from an older gentleman in Japan that was not technically literate but found the site via an unexpected keyword search and was actually trying to research a literary text. The pages were written for our own users, but ended up being read by some quite unexpected people (and I thought this was pretty cool). All of our users had access to the latest browsers with all the gizmos, but if I had made that page using CSS2, DHTML and the latest javascript tricks, it may have not been accessible to some of the unintended readers.
Point being, although I'm not your intended audience, I might read some of your sites some day, so don't piss me off:)
So do you have an alternative proposal to prevent resource (i.e. bandwidth) theft?
Session cookies based a cryptographic hash of browser-identifiable information. Just hashing the IP and some secret string will prevent the bandwidth-stealing problem (not ideal since it breaks with NAT, but that's irrelevant if you're only trying to solve the deep-linking problem).
In php, setcookie('hash', md5($ENV[REMOTE_ADDR] . "TOPSECRET)) on page load, link to a file "image.php" instead of the.jpg and "image.php" does something like this: if (getcookie('hash') != md5($ENV[REMOTE_ADDR] . "TOPSECRET")) { header("Location:/error-documents/403.html"); exit(); }. This isn't complete (probably not even syntactically correct and be careful with what image.php allows one to download), but you get the idea. The actual image files can't be downloaded by apache, but can only be opened and sent to the browser through "image.php". For extra fun, re-generate the secret string from/dev/random every ten minutes (and keep around the last version of the key to avoid breaking on-going sessions).
This stops everyone from stealing bandwidth (including telnet-wielding network programmers like me) and it annoys no one.
Re:Do we need yet another window manager (YAWM)?
on
What Happened to 5dwm?
·
· Score: 3, Insightful
OSS does not need managers.
I wrote a window manager because that's what I wanted to do and I was able to do it better than anyone else that's ever written a window manager (because I know what I want in a window manager and everyone else got it wrong when they tried). I don't care if you, or anyone, else finds my work useful - I posted the code because it doesn't cost me anything not to do so.
This is my spare time and I'll spend it as I see fit.
If you want me to write whatever god-awful financial database application you may consider useful for your business, you'll have to pay me because that's not fun. That's what I do at work - I write window managers and kernels at home because that's fun, and it's not as much fun dealing with the politics on other window manager projects.
Whoever said that we need some ridiculous system to pander to newbies like OS X or Windows? FreeBSD does everything I want it to do and if there's a problem that bugs me, I'll write a patch. I don't give a damn about its commercial success because I'm not getting a cut. As long as it's still alive with people like me and I can still use it, I'm happy.
If you're really worried about these issues, shut the hell up and write code. Don't come in to some project expecting to manage and direct it, because I don't take kindly to armchair managers.
I can send them directly there, give them a specific welcome message if they haven't been to my site before, etc.
This is so damned annoying. If I'm searching for some specific information, I don't give a damn about your idiotic welcome page. I don't care what your website is about or what you have to say on your other pages - all I care about is the specific technical information that google told me you have.
More and more, I'm finding myself using googles cache instead of clicking on the actual links. I know you couldn't care less about my insignificant browsing habits, but the more people start doing annoying crap like this, the more people start using google instead of the web.
"This page is restricted to users of xyz.com. Please go there first."
Do you realize how stupid this is? You're trying to control how I use my browser. Of course I'm not going to go to xyz.com and try to use their idiotic navigation looking for a link to you. You're simply advocating another form of advertisement and I'm not interested. I care about the data you're providing, not how you're getting funded.
I can use the referrer to limit the damage done by only allowing the images to be referred by pages from my own site.
And this is, of course, broken behaviour. Did you know that when you open a new link in Netscape/Mozilla that the browser does not send any referer at all? This means that I can't open your images in new windows and I'm constrained to view your images one at a time. Also, the some browsers change the referer for images when you "save" images (eg, right-click and choose "Save as..." may not send the referer you're expecting).
If taken away one restricts opportunities for the site operator to personalize and protect content on their site.
If you're using this to restrict content to your site... well, forget it. If you have something I really want, I'll open up a terminal and telnet to port 80. Yes, this is indeed effective restriction. (Quiz to see if you really know what you're doing: how would you set it up so that you know that a user has previously visited another site, with cryptographic confidence?)
As for "personalizing" content, please stop. The only times I've seen that word being used in a web context is to personalize advertising (and also restricting content because I'm not using IE, but don't get me started on that). I've never seen anyone "personalize" a site in a useful way, eg, "You're a C programmer who writes Solaris kernel modules, so you're probably not going to spring for my Herbal viagra scheme and I'm going to cut the marketing BS and give you only useful information."
Why do these "blogs" even keep logs of referer links? This is pure narcisism (and more importantly, a waste of disk space - even though disk is cheap, it's still worth more than someone else's paltry feeling of acceptance). If you're going to say something, just say it. Don't base your life around how many people like what you say. "Ohh, somebody linked to my journal, that means I'm special and I can now feel good about myself." Ahh - get a life.
I'm assuming you're advocating Apple's wares with your post, since the thread seems to be moving in that direction (and if you were a Free Software type, a PC laptop is much more suitable for running a truly Free OS than a TiBook or an iBook).
And of course Apple Computer is a saintly company, an example for all of us.
Nevermind that they will sue you at the drop of a hat if you design a "theme" with gel-colored drop-shadowed buttons.
Nevermind that they've been stiffing unix users over the QuickTime fiasco: when we ask them to release a binary-only codec so we can view Sorensen videos using xanim, they can't do that because Sorenson owns the rights to the codec. However, when Sorensen tries to sell the codec to Macromedia, Apple jumps in and claims that they have exclusive use of the Sorensen codec.
Nevermind that they're a premier member of the BSA, an organization based solely on blackmail and extortion.
Apple's hands are just as bloody as Microsoft's. Apple just has better marketing folks. You may be more willing to give Apple your money because they've built up an image - so their marketing tactics are effectve.
The only thing wrong with this laptop is that it will probably only be available bundled with a Windows license. The Apple alternative is no better if you're truly worried about your conscience. The best way out is to get a laptop with no OS preinstalled (or better yet, a laptop with Linux pre-installed).
This is a bug in the Kerberos admin daemon, which only runs on KDCs, which are centralized Kerberos servers. Clients are not affected. Furthermore, it only affects KDCs that have enabled version 4 backwards-compatibility.
If you don't know what Kerberos is, you don't have to patch your system. Only people that run KDCs have to patch their systems. I've never seen Kerberos installed with less than a few thousand users, so you would probably know if you're the admin of a KDC.
The fix is to design the CPU so it refuses to run code in an area designated as stack space
Modern CPUs do this. You can specify whether certain pages are executable or not, so you just set a couple of different bits in page table entries for pages allocated for stack to make the stack non-executable. The kernel will always know what pages are allocated for a program's stack because the kernel allocates the initial stack and sets the stack pointer, and the way a program's stack grows is by accessing an address lower than what is available, which generates a page fault, which in turn lets the kernel know that the program needs more stack space. Somewhere in the kernel there's some heuristic for determining whether or not a page fault is due to the stack growing. (eg, what happens if you just access memory right in between the stack and top of heap? Try it on your favorite Unix, then try incrementing that address until it no longer segfaults.)
The short of it is that modern CPUs do not require any additional hardware support to make the stack non-executable.
I'm pretty sure sun/sparcs can keep track of stack space as well if you supply some weird option in the bios
Sparcs don't have a BIOS. It's called Open Firmware, and it's completely different from a PC BIOS (for one thing, Open Firmware implements a real programming language in ROM).
The essential paradigm of cyberspace is creating partially situated identities out of actual or potential social reality in terms of canonical forms of human contact, thus renormalizing the phenomenology of narrative space and requiring the naturalization of the intersubjective cognitive strategy, and thereby resolving the dialectics of metaphorical thoughts, each problematic to the other, collectively redefining and reifying the paradigm of the parable of the model of the metaphor.
The source of the above paragraph should serve as an adequate introduction to postmodernism.
Just for fun, I decided to see how fast I could write this patch (never having examined Linux source code before).
The way I set it up is that RSTs that originate from misdirected SYN|ACK will be sent with a IPID of zero, but other regular RSTs will be sent with incremental IPIDs.
This is not the way other OSes do it and it confuses nmap (because IPID will be incremental for most RSTs, but not when receiving a misdirected SYN|ACK). The wise scholar will note that this may open you up for another zombie attack, but it prevents nmap from working (so it stops the kiddies:).
Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Idlescan using zombie 172.16.42.245 (172.16.42.245:7); Class: Incremental Your IPID Zombie (172.16.42.245; 172.16.42.245) is behaving strangely -- suddenly cannot obtain valid IPID distance. QUITTING!
This is great fun:)
Here's the patch, against kernel 2.2.22:
Actually, fuck it. I'm spending more time trying to get the god-damned patch past the lameness filter than it took me to write the piece of shit. It's a fucking 24-line patch, but apparently, I must describe the details in slashdot-grammar English instead of C. Jesus.
Reply to this post if you want me to send it to you by mail from some throw-away account (trying to keep some semblance of anonymity).
CALL TO PERL PROGRAMMERS: I need a slashdot anti-lameness-filter filter. I just spent two hours in the bowels of Linux TCP - I'm not up for perl right now.
This keyboard cannot describe how livid I am right now. I AM NOT VERY HAPPY WITH YOU SLASHDOT.
Note: I've never heard of this before, but I do a fair amount of network programming. The article is quite informative, however.
This is pretty easy. Just throw a stateful firewall in front of your Linux boxen. Set it up so that it does not send a RST unless it has a session going. I can show you the appropriate ipfw or ipf rules if you're OK with throwing them behind a BSD box (not too fond of the Linux firewall stuff). You could also run a host-based firewall on the machines, but Linux 2.2 does not do stateful firewalls (and if you were running 2.4, this wouldn't be an issue).
You didn't mention what exactly your Linux cluster does. If it's a computational cluster, throwing it behind a firewall is a no-brainer. OTOH, if it's a server cluster, this might be more difficult.
I can write a kernel patch to do something clever - but this is completely pointless since Linux 2.4 already does peer-specific IPID numbers. I'm guessing you cannot upgrade your Linux cluster to 2.4 (which is perfectly legitimate), so it might be worthwhile to back-port the changes. Perhaps it would be much easier to set DF in all RST packets and simply zero the IPID for packets with DF set - this should be a much easier change, touching much less code than peer-specific IPID numbers. Let me know if anyone wants this, and I should be able to cook something up:)
the main reason why i didn't like the BSD/ports... having to compile a whole batch of file
It is indeed a pain sometimes. If it's only a few ports, you can create a binary installation thing (sort of like an rpm or a deb) like this:
pkg_create -b zsh-4.0.4/tmp/zsh.pkg
Idea is, you download and install your ports on a big fast machine and then you can just install the binaries on the slower machines by copying over the package and doing something like this:
pkg_add zsh.pkg.tgz
You can, of course, script this if it's a larger number of packages (another trick: export/usr/obj via NFS). Theoretically, you could just distribute the pkg.tgz files to FreeBSD and do away with cvsup and ports, as these pkg files know about dependencies and whatnot. The reason nobody does that is because it's useful to always have the source code and it's useful to build all your software from source (so you can control compilation flags).
I still prefer ports and build world to all the linux "package management" stuff because I actually use the source: if there's a really nasty bug that I need to trace down into libc, just cd/usr/src/sys/lib/libc. If I want to add a switch to "find" cd/usr/src/usr.bin/find. If I don't like the compilation flags for mutt, cd/usr/ports/mail/mutt/work. This happens often enough that I don't want to have to deal with searching the web for srpms and whatnot (I always want the source right there with the binary).
You seem to have added him to your friends, though, possibly in error?
No, actually that was intentional. He's the kind of troll that I like: the old-style troll like you would find on usenet. The idea is that you post something which seems meaningful and controversial to newbies, but which is immediately recognized as utter bullshit by the clueful.
This is funny. For instance, look at this post. I still laugh at that when I look back: "just in time assembling?!" What really gets me is that someone may have taken that BS seriously (I can just imagine someone nodding vigorously in agreement, afraid to admit that they've never heard of "pipeline overflow caching"). This would be even better in person, eg. as the subject of conversation at a high-brow pseudo-intellectualist dinner party.
Now, when people start taking him seriously, that makes me look bad since I also post to this website.
Slashdot Mirror
Have you read this? Your satire seems inspired by postmodern literary critique. It also has the elements of a good BS "paper," and I'm guessing you picked this up at Columbia. This style is a large part of what got me through the common core courses.
Do you realize how ridiculous your words are? "Legacy" 32-bit environments? Like the "legacy" 32-bit environment with the "legacy" operating system that you used to type into slashdot? So it's cleaner to make the maximum filesystem size depend on the machine's pointer length than it is to simply write better software, even if writing better software means resorting to traditional ("legacy" as you might call it) methods?
The "single opcode MOV?" You do realize how mmap works? Certainly the user-level program can simply access it like memory, but this then goes through the VM (by means of a hardware interrupt on page fault) which calls some disk subsystem, which will eventually end up calling a disk driver. End result is that you write something to the disk. There is no magic MMU hardware which understands EIDE or SCSI and maps memory to disk blocks - this is done through code. It's merely an abstraction to transfer the complex parts of the code into another layer of software, made necessary because of the poorly-thought-out layers of software.
How can a single MOV be considered "elegant" when you have to keep a data structure of which parts of the partition are mapped? Your single MOV instruction becomes a series of instructions to select a "view" of a partition, clean out old "views," and map new ones when needed. It won't be a MOV, it will be a function call into some library. How is this more clean than simply calling pread()? Of course, as you say, this is only a "temporary hack" - you can get rid of this once everyone is using 64-bit architectures.
It's not "clean" or "elegant" in any sense of the word. The mmap is a nasty hack because someone couldn't figure out how to use the same cache management that the VM uses in a user-level process. Someone simply chose a poor abstraction. It's a mistake, and I simply cannot understand how someone could let such a stunning error into any operating system.
I hate to spoil your naivete, but Intel and AMD don't give a damn about HURD, and they certainly don't design their hardware with this sort of thing in mind. Although the theoreticians don't like this, computer hardware is complex and non-orthoganal. If the HURD was designed to run on only 64-bit machines with clean MMUs, you'll be waiting a long time until HURD is stable on readily-available hardware. (Does HURD even support 64-bit architectures at this time? If not, then how can you possibly justify the mistake of having filesystem drivers use mmap?)
I don't give a damn about the politics. This is simply bad design. You can attack me with all sorts of accusations that I don't approve because of whatever politics, but this does not change the fact that someone made an immense error when designing the filesystem servers and certain people thought this error was "elegant."
I really didn't mean to flame you personally, but this is inexcusably bad design. I don't understand how someone can justify it, rather than admitting that it's a fundamental design problem.
This is completely nuts.
I can appreciate that the filesystem driver is a userland process - this means I can write a "filesystem" as a normal userland process (eg, make some things have a filesystem-like interface, so you can do interesting things with databases like make /etc/passwd a directory). This is a cool idea.
However, using mmaping an entire partition is just crazy. This is poor design. What were they thinking?
Are they trying to avoid the system call overhead for seek() calls? This is the only reason I can think of that someone would do this - when you read/write/seek, you have to do a system call for seek(), but that comes "for free" when you mmap() because you specify the address. This would only be a problem with HURD-like systems, because there is no overhead if the filesystem driver runs in kernel space along with whatever other subsystems it needs to use.
I know everyone hates backseat designers, but I'd like to know if the following approach has been considered:
Make two new system calls, say "readaddr" and "writeaddr". These work like read and write, except that you also specify an offset (perhaps with a "whence" field like lseek). This saves you the overhead of calling seek all the time by combining the operations into one system call. This might be useful for other things as well, but I would imagine a filesystem driver is one speed-critical piece of code that does a lot of jumping around. Actually, I just remembered that there already are calls for this: pread/pwrite.
Another possible approach: using mmap is nice, but mapping in an entire partition is fubar. Why not map in specific parts of the partition as they become needed? Eg, keep superblock mapped right away from startup, and map in other parts as they are needed. Seems a bit complex, but could be done more easily with another layer of abstraction (some library which keeps a hash or something of mmap()ed bits and provides a nice interface for filesystem drivers). I'm guessing mmap was used as this transfers certain operations (eg, cache management) "deeper" into the "kernel" and avoids code duplication.
But anyway, mmaping an entire partition is really nuts. They're not getting any sympathy from me.
Portability fix, standards compliance:
This is called "Delivery Status Notification" and has been a standard for some time now.
Before the Internet was big, I worked with proprietary (non-SMTP) inter-office mail systems. I remember one system in particular had this feature where it would display the status of a message to the message sender or administrator. A message would be marked "read" if the user lingered on the message for some configurable amount of time (remember, this was non-standard mail, so the vendor wrote both the client and the server).
I'm certain you can see the problems with this system: it's something of an invasion of privacy. Boss sends user a mail, user doesn't complete task in mail before lunch, boss confronts user, user claims he only had time to skim over the message, boss tells admin to pull out the logs.
Anyway, this can result in some pretty nasty situations, so I'm guessing the reason this hasn't been widely-implemented is because users actually don't want this (I just read through the standard and I can see a number of other technical problems which have possibly delayed its acceptance). I certainly don't want anything like this (even without that evil MUA behaviour described above, this sort of raises the bar for email, making it a "more serious" medium, and that changes the nature of what goes through email (consider what goes through email and why you would never receive a subpoena or summons through email)). If I had to complete every hair-brained idea sent to me through email from management, I would never get any work done. Without status notification, I can postpone this for a couple of days until I actually speak with the person involved and they've already forgot about the idea or we have a chance for a two-way conversation and I can convince them how bad their idea is.
I prefer keeping some anonymity on Slashdot (lets me rant more easily), but if you come across me on the Internet otherwise, you'll recognize me by my .sig, which is a three-line PostScript program (albeit not nearly as cool as the raytracer).
PostScript is an amazing language - completely changed the way I thought about programming. Bored with systems-level C programming? Give PostScript a try....
Excellent start. vi is the proper editor for these sessions.
The problem with Emacs? You're writing a lexer. You probably have a bunch of similar-looking statements for various keywords. Each statement is probably a little bit different, so cut-and-paste becomes tedious. Or, perhaps you have a table of thirty numbers in hex, which change using some complicated pattern. Perhaps there's some way to automate this, so you can lay out some sort of table, and have Emacs generate code and automatically indent it? Of course Emacs can do that. Why, all you have to do is read in the first character using thing-at-point, convert it to an integer and then use a bit of recursion...of course, this could be more generally useful, so you might as well add it to your .emacs - ah, but you forgot to call save-excursion, so it's not a very user-friendly function...
STOP! No Lisp programming. Must write lexer.
Warmth. I find if I'm at home and dont put a pair of socks on I curl up in my seat, not very efficent
No, no, no. Must keep it cold. When it's warm, it's too easy to fall asleep. The colder, the better. If the temperature bothers you, repeat after me: Cold is the mind-killer. I will allow cold to pass over me. Cold is the mind-killer.
Incremental backups. maybe a cron job, tar your files at least every hour, preferably every ten minutes.
One word: CVS :) Important for larger projects, critical for marathons. cvs diff can answer the eternal question of "WTF was I thinking?"
Dont be hungry. Start getting hungry? Order a pizza (online).
Again, too easy to fall asleep after eating. Warm with full belly = nap time.
My own suggestion? Lots of liquids. You can only consume so much caffeine before experiencing psychadelic effects, so you'll also need water, and lots of it. This is not a preventative measure, but is rather disaster recovery: if you do fall asleep, you won't sleep long before the call of nature, and when you get up, you'll feel so guilty about "lying down for a moment" that you'll write your best code.
Good luck with the project - I imagine you're probably at the parser at this point, so go get those S/R conflicts :)
This is probably the reason. MySQL gets the press, so PHBs are OK with it. Postgres gets no press, so PHBs are wary of it.
I had a PHB that was wary of using a free database for some incredibly trivial web database. I explained to him how using Sybase was a bad idea since he would need a competent *nix admin perpetually in the department to do simple things like backups, and how MSSQL has a bad security record, etc. This particular app just needed to do a couple of joins from php - it didn't even need to open up the SQL server to the world, only running locally on the web server. I couldn't possibly legitimze paying something for the trivial project, but the PHBs somehow thought that if we bought an MSSQL license, we would be treated to red-carpet support directly from Microsoft developers.
You know what convinced him to give the go-ahead to MySQL? MacOS X ships with MySQL. That means it's a serious product, not some fly-by-night sourceforge/freshmeat project written by a college kid between classes. Doesn't matter if more people use Postgres for more serious things. All that matters is if there's a big name behind it. Same thing with FreeBSD - they all wanted only Linux before Apple started advertising that their stuff was based on FreeBSD 4.4.
That's how things work in Corporate America. Those making the technical decisions often aren't the ones with the technical knowlege.
Keeping all the state server-side is the most secure option, and the one least likely to break.
I've done a few things trying to keep state client-side in cookies - but it's proven too unreliable (in addition to people who don't accept cookies, you have to deal with browser bugs, clients whose clocks are not set correctly, and so on). I mostly just keep it server-side now, like you suggest. The only downside is that, well, you're keeping the state server-side. Even with a lot of traffic, this isn't really all that much overhead, however. I've also noted that for something this simple, using a database is actually faster than keeping the state in some file (at least with persistent database connections). But this in itself probably doesn't warrant having a database if the site doesn't need a database for anything else.
So, yeah, this is probably the best way, but it feels a little icky keeping this kind of state server-side when it could easily be offloaded onto the clients.
Another possibility I just thought of: on the main page, you generate your image links to look like this: image.php?code=2476DA8DA77FF349890ACB66" where the "code" is a hash of the IP, a timestamp and some secret string. image.php can then check the hash to make sure it matches up, and you don't end up keeping anything server-side and it doesn't have any extra file or database overhead.
Anyway, lots of possiblities - no need to use referer.
The point of the session cookies was to ensure, with cryptographic confidence, that a user has seen your main page before allowing them access to your images. Referer headers can be faked, but not the session cookies I described (eg, you can inject them into a wget session, but only after you've actually seen that main page from that specific IP).
Anyway, this is irrelevant - both will do fine for controlling your outgoing bandwidth, and I'm not really concerned about the "privacy" issue (if there even is a privacy issue - read my original post carefully, and you'll see that I don't care whether or not someone logs my referer, but I do care when it breaks my browsing session or they try to stupid things with the header like redirecting away from the data that originally attracted me; I'm perfectly OK with anyone logging all the headers my browser sends (although this is asinine pubescent behaviour in the case of these blogs), because, after all, that's what I sent to them).
My point is that using the referer header breaks under certain conditions - when I open an image in a new window, or when I "save" an image - but the session cookies I describe don't break under the same conditions. It's about broken, stupid behaviour, not some nutcase "privacy" thing.
The first software would be run only the first time you get your broadband installed. It would go through the steps of creating an account with a username/password etc. and it may automatically create an email account for you. It would also probably change a few settings (email/DNS server and whatnot) and it may install a "branded" version of IE. This software may also record your MAC address, which is not very nice (this would mean that the service is restricted to the machine with which you run the stupid little program). This is, of course, some stupid Windows program, but you may actually need an account before being able to use the service.
Hint: sometimes this software is just a little wrapper that invokes IE as a COM object and simply displays web pages. I know that SBC does this. To see if that's the case, right-click in the program and see if you get IE's popup menu. You can then bookmark the page to figure out the URL and you can complete the registration from any web browser instead of using the software.
Any software used to initially register the service can of course be removed after registering the service.
The second class of software it might install is PPPoE software (PPP over ethernet). ISPs are increasingly using this to provide DSL and cable service. I don't like this one bit, and I still can't figure out what possible advantage running PPPoE would have at their end except that they may be able to use some older software designed primarily for PPP (eg, RADIUS, mrtg on the PPP server software, etc).
If your ISP uses PPPoE, you'll need PPPoE software, depending on what OS you run. I believe Windows XP comes with a built-in PPPoE client, I know MacOS X 10.2 does, and I know Windows 9x and MacOS 8-9 definitely do not come with PPPoE software. FreeBSD comes with its own PPPoE client, but Linux usually does not (for Linux, you may have to download "Roaring Penguin PPPoE" - hit google).
So, the procedure would be: have a Windows box handy when you get your broadband. Since the software might register your MAC, make sure the Windows box has the same MAC address as your eventual NAT box (eg, swap out the NICs if necessary). Install the software and then figure out what it does. You might be able to use the account-creation stuff without their software like I did, but it's probably no big deal to go through their stupid little wizard. Then you figure out what kind of network setup they're using (whether or not it's PPPoE), configure your NAT appropriately, and drop their software.
If you're new to this, you should know a couple other things: first, you'll want NAT if you have more than one machine. NAT allows you to put all your machines behind your NAT router and your provider only "sees" your NAT box (I'm aware of how ISPs can attempt to detect NAT and how "stealth NAT" can defeat that, so there's no need to go into that here). FreeBSD makes an excellent NAT server that can run on really old hardware (you'll of course need two NICs, but there's no hardware requirements other than that) - the FreeBSD handbook has a section especially on this, and setting up NAT involves simply editing a few lines in /etc/rc.conf (and you'll probably want to install a DHCP server on the inside side of your NAT, and that's only a port install away). It litteraly takes two minutes to set up a FreeBSD NAT box from a default FreeBSD install. There are also several Linux floppy-based distributions that are designed specifically to run NAT.
The second thing you should know is that some ISPs discourage running servers by make your DHCP-assigned IP "very dynamic" (eg, it changes every few days no matter what). If you still want to be able to ssh into your box, you could use something like dyndns.org, or you could simply write a little script that "publishes" your IP on a web site or something whenever your IP changes.
How many people even know how to point a telnet seesion - and are they even in your web site's intended audience?
I believe this kind of reasoning is a bit dangerous - it's very difficult to gauge your audience. You can, of course, gauge your intended audience, but you're always going to get some people in there that don't fit the demographic.
Example: a couple of years ago I wrote a bit of technical documentation for a system we were using internally in my department. I also linked it in from a couple of places, but I didn't restrict it to our local network since it wasn't any kind of secret.
I was quite surprised at some of the responses I got from that page. I, of course, didn't log referers, but I occasionally received mail from random people who found the site via a search engine. One mail was from a guy in India who needed some help with a technical problem and he found our site, and another mail was from an older gentleman in Japan that was not technically literate but found the site via an unexpected keyword search and was actually trying to research a literary text. The pages were written for our own users, but ended up being read by some quite unexpected people (and I thought this was pretty cool). All of our users had access to the latest browsers with all the gizmos, but if I had made that page using CSS2, DHTML and the latest javascript tricks, it may have not been accessible to some of the unintended readers.
Point being, although I'm not your intended audience, I might read some of your sites some day, so don't piss me off :)
Session cookies based a cryptographic hash of browser-identifiable information. Just hashing the IP and some secret string will prevent the bandwidth-stealing problem (not ideal since it breaks with NAT, but that's irrelevant if you're only trying to solve the deep-linking problem).
In php, setcookie('hash', md5($ENV[REMOTE_ADDR] . "TOPSECRET)) on page load, link to a file "image.php" instead of the .jpg and "image.php" does something like this: if (getcookie('hash') != md5($ENV[REMOTE_ADDR] . "TOPSECRET")) { header("Location: /error-documents/403.html"); exit(); }. This isn't complete (probably not even syntactically correct and be careful with what image.php allows one to download), but you get the idea. The actual image files can't be downloaded by apache, but can only be opened and sent to the browser through "image.php". For extra fun, re-generate the secret string from /dev/random every ten minutes (and keep around the last version of the key to avoid breaking on-going sessions).
This stops everyone from stealing bandwidth (including telnet-wielding network programmers like me) and it annoys no one.
I wrote a window manager because that's what I wanted to do and I was able to do it better than anyone else that's ever written a window manager (because I know what I want in a window manager and everyone else got it wrong when they tried). I don't care if you, or anyone, else finds my work useful - I posted the code because it doesn't cost me anything not to do so. This is my spare time and I'll spend it as I see fit.
If you want me to write whatever god-awful financial database application you may consider useful for your business, you'll have to pay me because that's not fun. That's what I do at work - I write window managers and kernels at home because that's fun, and it's not as much fun dealing with the politics on other window manager projects.
Whoever said that we need some ridiculous system to pander to newbies like OS X or Windows? FreeBSD does everything I want it to do and if there's a problem that bugs me, I'll write a patch. I don't give a damn about its commercial success because I'm not getting a cut. As long as it's still alive with people like me and I can still use it, I'm happy.
If you're really worried about these issues, shut the hell up and write code. Don't come in to some project expecting to manage and direct it, because I don't take kindly to armchair managers.
This is so damned annoying. If I'm searching for some specific information, I don't give a damn about your idiotic welcome page. I don't care what your website is about or what you have to say on your other pages - all I care about is the specific technical information that google told me you have.
More and more, I'm finding myself using googles cache instead of clicking on the actual links. I know you couldn't care less about my insignificant browsing habits, but the more people start doing annoying crap like this, the more people start using google instead of the web.
"This page is restricted to users of xyz.com. Please go there first."
Do you realize how stupid this is? You're trying to control how I use my browser. Of course I'm not going to go to xyz.com and try to use their idiotic navigation looking for a link to you. You're simply advocating another form of advertisement and I'm not interested. I care about the data you're providing, not how you're getting funded.
I can use the referrer to limit the damage done by only allowing the images to be referred by pages from my own site.
And this is, of course, broken behaviour. Did you know that when you open a new link in Netscape/Mozilla that the browser does not send any referer at all? This means that I can't open your images in new windows and I'm constrained to view your images one at a time. Also, the some browsers change the referer for images when you "save" images (eg, right-click and choose "Save as..." may not send the referer you're expecting).
If taken away one restricts opportunities for the site operator to personalize and protect content on their site.
If you're using this to restrict content to your site ... well, forget it. If you have something I really want, I'll open up a terminal and telnet to port 80. Yes, this is indeed effective restriction. (Quiz to see if you really know what you're doing: how would you set it up so that you know that a user has previously visited another site, with cryptographic confidence?)
As for "personalizing" content, please stop. The only times I've seen that word being used in a web context is to personalize advertising (and also restricting content because I'm not using IE, but don't get me started on that). I've never seen anyone "personalize" a site in a useful way, eg, "You're a C programmer who writes Solaris kernel modules, so you're probably not going to spring for my Herbal viagra scheme and I'm going to cut the marketing BS and give you only useful information."
Why do these "blogs" even keep logs of referer links? This is pure narcisism (and more importantly, a waste of disk space - even though disk is cheap, it's still worth more than someone else's paltry feeling of acceptance). If you're going to say something, just say it. Don't base your life around how many people like what you say. "Ohh, somebody linked to my journal, that means I'm special and I can now feel good about myself." Ahh - get a life.
I swear, "webmasters" piss me off.
And of course Apple Computer is a saintly company, an example for all of us.
Nevermind that they will sue you at the drop of a hat if you design a "theme" with gel-colored drop-shadowed buttons.
Nevermind that they've been stiffing unix users over the QuickTime fiasco: when we ask them to release a binary-only codec so we can view Sorensen videos using xanim, they can't do that because Sorenson owns the rights to the codec. However, when Sorensen tries to sell the codec to Macromedia, Apple jumps in and claims that they have exclusive use of the Sorensen codec.
Nevermind that they're a premier member of the BSA, an organization based solely on blackmail and extortion.
Apple's hands are just as bloody as Microsoft's. Apple just has better marketing folks. You may be more willing to give Apple your money because they've built up an image - so their marketing tactics are effectve.
The only thing wrong with this laptop is that it will probably only be available bundled with a Windows license. The Apple alternative is no better if you're truly worried about your conscience. The best way out is to get a laptop with no OS preinstalled (or better yet, a laptop with Linux pre-installed).
Then you're not affected.
This is a bug in the Kerberos admin daemon, which only runs on KDCs, which are centralized Kerberos servers. Clients are not affected. Furthermore, it only affects KDCs that have enabled version 4 backwards-compatibility.
If you don't know what Kerberos is, you don't have to patch your system. Only people that run KDCs have to patch their systems. I've never seen Kerberos installed with less than a few thousand users, so you would probably know if you're the admin of a KDC.
Modern CPUs do this. You can specify whether certain pages are executable or not, so you just set a couple of different bits in page table entries for pages allocated for stack to make the stack non-executable. The kernel will always know what pages are allocated for a program's stack because the kernel allocates the initial stack and sets the stack pointer, and the way a program's stack grows is by accessing an address lower than what is available, which generates a page fault, which in turn lets the kernel know that the program needs more stack space. Somewhere in the kernel there's some heuristic for determining whether or not a page fault is due to the stack growing. (eg, what happens if you just access memory right in between the stack and top of heap? Try it on your favorite Unix, then try incrementing that address until it no longer segfaults.)
The short of it is that modern CPUs do not require any additional hardware support to make the stack non-executable.
I'm pretty sure sun/sparcs can keep track of stack space as well if you supply some weird option in the bios
Sparcs don't have a BIOS. It's called Open Firmware, and it's completely different from a PC BIOS (for one thing, Open Firmware implements a real programming language in ROM).
The source of the above paragraph should serve as an adequate introduction to postmodernism.
Hmm...yes....
Well, I have a kernel for you to run. Just send me your config, and I'll send you a bzImage. Problem solved!
All that's missing is the web server part, but I can fix that once a few people start using my kernels :)
The way I set it up is that RSTs that originate from misdirected SYN|ACK will be sent with a IPID of zero, but other regular RSTs will be sent with incremental IPIDs. This is not the way other OSes do it and it confuses nmap (because IPID will be incremental for most RSTs, but not when receiving a misdirected SYN|ACK). The wise scholar will note that this may open you up for another zombie attack, but it prevents nmap from working (so it stops the kiddies :).
This is great fun :)
Here's the patch, against kernel 2.2.22:
Actually, fuck it. I'm spending more time trying to get the god-damned patch past the lameness filter than it took me to write the piece of shit. It's a fucking 24-line patch, but apparently, I must describe the details in slashdot-grammar English instead of C. Jesus.
Reply to this post if you want me to send it to you by mail from some throw-away account (trying to keep some semblance of anonymity).
CALL TO PERL PROGRAMMERS: I need a slashdot anti-lameness-filter filter. I just spent two hours in the bowels of Linux TCP - I'm not up for perl right now.
This keyboard cannot describe how livid I am right now. I AM NOT VERY HAPPY WITH YOU SLASHDOT.
I'm guessing the original poster read the article he linked to and that he's looking for a solution for Linux 2.2. This requires a kernel patch.
This is pretty easy. Just throw a stateful firewall in front of your Linux boxen. Set it up so that it does not send a RST unless it has a session going. I can show you the appropriate ipfw or ipf rules if you're OK with throwing them behind a BSD box (not too fond of the Linux firewall stuff). You could also run a host-based firewall on the machines, but Linux 2.2 does not do stateful firewalls (and if you were running 2.4, this wouldn't be an issue).
You didn't mention what exactly your Linux cluster does. If it's a computational cluster, throwing it behind a firewall is a no-brainer. OTOH, if it's a server cluster, this might be more difficult.
I can write a kernel patch to do something clever - but this is completely pointless since Linux 2.4 already does peer-specific IPID numbers. I'm guessing you cannot upgrade your Linux cluster to 2.4 (which is perfectly legitimate), so it might be worthwhile to back-port the changes. Perhaps it would be much easier to set DF in all RST packets and simply zero the IPID for packets with DF set - this should be a much easier change, touching much less code than peer-specific IPID numbers. Let me know if anyone wants this, and I should be able to cook something up :)
It is indeed a pain sometimes. If it's only a few ports, you can create a binary installation thing (sort of like an rpm or a deb) like this:
pkg_create -b zsh-4.0.4 /tmp/zsh.pkg
Idea is, you download and install your ports on a big fast machine and then you can just install the binaries on the slower machines by copying over the package and doing something like this:
pkg_add zsh.pkg.tgz
You can, of course, script this if it's a larger number of packages (another trick: export /usr/obj via NFS). Theoretically, you could just distribute the pkg.tgz files to FreeBSD and do away with cvsup and ports, as these pkg files know about dependencies and whatnot. The reason nobody does that is because it's useful to always have the source code and it's useful to build all your software from source (so you can control compilation flags).
I still prefer ports and build world to all the linux "package management" stuff because I actually use the source: if there's a really nasty bug that I need to trace down into libc, just cd /usr/src/sys/lib/libc. If I want to add a switch to "find" cd /usr/src/usr.bin/find. If I don't like the compilation flags for mutt, cd /usr/ports/mail/mutt/work. This happens often enough that I don't want to have to deal with searching the web for srpms and whatnot (I always want the source right there with the binary).
No, actually that was intentional. He's the kind of troll that I like: the old-style troll like you would find on usenet. The idea is that you post something which seems meaningful and controversial to newbies, but which is immediately recognized as utter bullshit by the clueful.
This is funny. For instance, look at this post. I still laugh at that when I look back: "just in time assembling?!" What really gets me is that someone may have taken that BS seriously (I can just imagine someone nodding vigorously in agreement, afraid to admit that they've never heard of "pipeline overflow caching"). This would be even better in person, eg. as the subject of conversation at a high-brow pseudo-intellectualist dinner party.
Now, when people start taking him seriously, that makes me look bad since I also post to this website.