The "rant" was the result of me being extremely pissed. And I believe justifiably so. There was something in the kernel that Andre
considered a "defect." He had a simple piece of code to fix it. The kernel people rejected this, because "in theory, someone can
get around this, so there's no point plugging a hole which someone can reopen."
In theory? This was like setting a policy that if you sell a gun to an ex-con, it must be sold with the safety catch set. Sure, criminals can "in theory" turn off the safety themselves, but hey, it's better than nothing, right? At least "by default" they can't go out and start shooting people, right?
...Wait. Did you just call Andre's taskfile patch "simple"? Maybe you're one of those people who consider ACPI parsing "simple" too? Have you even read the patch, or was this just hearsay?
For those of you who weren't following along back then, Andre wanted to provide an ioctl-based way to run vendor-specific, often undocumented hard disk commands. This would be things like "make disk read-only" or "unlock extra 10 GB of space the firmware rounded down so they could sell those excess 40GB drives as 30GB" or such. Being vendor-specific and often undocumented commands, the applications that used them might be buggy and, if buggy enough, might be able to turn a hard disk into a paperweight.
The taskfile patch was intended to provide sanity checking in the kernel to guard against buggy applications. Of course, Andre being Andre, he didn't put it that way. By the time he was done yelling, it sounded as though EVIL HACKERS WILL DESTROY YOUR HARD DISKS IN THE BLINK OF AN EYE AND IT'LL BE ALL LINUX'S FAULT. Never mind that the EVIL HACKER already needs to crack root before he gets the necessary raw hard disk access. Never mind that the taskfile patch would not prevent the EVIL HACKER from bypassing the ioctl interface and bit-banging the ATA chip directly. Never mind that, as root, there are a lot of horrible things an EVIL HACKER could do to your system, much more insidious and EVIL than crashing a hard drive, like installing backdoors and making your system fail in subtle ways that you wouldn't notice for a month. Never mind that those same EVIL HACKERS have been able to destroy these same hard disks in any version of Linux or Windows since the beginning of time (well, the beginning of ATA hard disks with these command sets) and yet somehow, remarkably, we haven't yet heard of it being done.
And never mind the whole problem that if a buggy application can destroy your disk, so can a buggy taskfile patch. (Andre tends to exude an abnormally high level of confidence in the quality of his implementations.)
In short, at the risk of sounding like I know what I'm talking about, which I don't really, it was a stupid idea. At least as initially presented on the mailing list. Some time later, the startling revelation came out that the taskfile patch actually had some other uses besides the one listed above (protecting against EVIL HACKERS DESTROYING YOUR HARD DISKS AS YOU SLEEP). And then, marvel of marvels, Linus was suddenly a lot more sympathetic to the patch.
I made some remark about how it would boost user morale if the patch were in place, regardless of any real technical
merit. I made some statement to the effect of, "You guys should care more about what the users want, even if you think you know better than them."
And that, at the risk of sounding like one of your alleged arrogant pricks on linux-kernel, is idiotic too. Hard to explain what's so utterly wrong with your statement - I guess it's just one of those things - if you have to ask, you'll never know. (Now how's that for elitist?...)
Yeesh - I never even knew that
bracketing styles had their own fucking terminology before.
So what do you type when M-x c-set-style asks you to pick a style? (:
Your choices, btw, are: "bsd", "cc-mode", "ellemtel", "gnu", "java", "k&r", "linux", "python", "stroustrup", "user", and "whitesmith". Many of these are only subtly different from each other - frex, "linux" is basically "k&r" with an 8-space basic offset.
That's why these styles need actual names - you can just blame it all on Emacs. (:
There's a snag here. Some systems out there on the Internet allow users to set "out of office" notifications. Said systems are not
always intelligent enough to notice that their "response" is not to a human.
Very good point. The opt-in mail should be sent priority 'bulk' meaning it's a form letter - perhaps that will prevent these vacation programs from auto-replying. But you're right, it's far from certain.
The generally accepted best practice is to offer both a "click here to confirm" link, and "reply to this message, keeping just the
line that starts with 'subscribe' if you don't have web access".
That would work. Or something like "simply reply to this message, quoting this text, but add the word CONFIRM to the subject line."
I loved the message that asserted that "you" opted in from IP address 10.0.0.12. Who was this "you"? A guy called
"MAILER-DAEMON@example.com. Yeah right, that convinced me that Mailer daemon subscribed to the penis enlarger info. My Mailer
Daemon doesn't even _have_ a penis, dunno about theirs.
Remember the original meaning of the word daemon - maybe you do have one in your mail system somewhere, and it does have a penis, and wants a bigger one.
I am located in the United States, and use mplayer to watch encrypted DVD's on my Linux PC.
Am I breaking the law (DMCA)?
Technically it is not illegal to use mplayer to watch your DVD - at least, assuming nobody has a patent on the various bits of MPEG2 contained therein. (Because mplayer doesn't have the appropriate patent licenses. Although, if you own a copy of Quicktime or WMP, you probably have such a patent license, in which case you're fine. And since both QT and WMP are free downloads, you can thus acquire a patent license quite easily just by downloading the executables.)
But it is a DMCA violation to distribute mplayer. So those Hungarians are in big trouble, as are you if you put it up for your friends to download.
Of course, that is relying on the pedantic, literal interpretation of the DMCA. And we all know how far that goes when Adobe picks up the phone and sics the FBI on you.
So... if opt-in is to work, there has to be some add'l layer of caution such as a practical methods of authentication.
Suggestions? The snadard now is to send a single email requesting a reply before the opt-in is confirmed. Is there a way to spoof
this?
Are you talking about snail mail or email opt-in? For email opt-in, it's pretty easy. You send the subscribee a confirmation mail containing a random number string, and if they send it back (just hit 'reply' and quote the whole thing) they're confirmed.
The only way to spoof this is to gain access to the victim's mailbox, so you can receive the confirmation mail with the random number in it. And if you have access to the victim's mailbox (or a router in between, etc) there is nothing that can prevent opt-in spoofing, short of everyone having pgp or some other pki, with a web of trust spanning the whole world. Like that's ever gonna happen.
Re:IDE Raid, inexpensive but major hassle
on
IDE RAID Examined
·
· Score: 1
it is not the serial ata spec but the IDE spec. Even a dual channel ide card can actually only write to a single
channel at any time.
You sure about that? Even the original ISA-based IDE interface has two separate port ranges and two IRQs for the two channels. That to me implies that you can treat them as independent interfaces. If both channels are handled by a single chip which is limited to a single command at a time, that is a mere implementation detail.
I seriously doubt the SATA specs tie the hands of the hardware people in such a way as to forbid multiple ports to be treated as independent entities. (Especially now, with PCI being all the rage - PCI has a provision for providing multiple independent "functions" per bus address - that is, per PCI card or per motherboard chip.) If there is such a limitation, I expect it only affects the old ISA IDE compatibility mode (i.e. what your OS uses if it doesn't have a specific driver for the SATA chip in question).
If you have good information to the contrary, I shall have to accept it, but I'll be surprised.
Re:IDE Raid, inexpensive but major hassle
on
IDE RAID Examined
·
· Score: 1
I've got a promise card with 4 channels and serial ata adaptors. While it looks great it has the same issue any other IDE controller has, only a single channel access at any one time so it is just a shell game.
Hmm. Bug in the Promise design, then. Serial ATA is designed for "one cable, one device" (no more master/slave) but different cables - aka different channels - should run just fine in parallel.
Actually, it may not be a design bug, but a driver limitation. Who knows - I don't have your card. It's not a shortcoming of the SATA spec, though.
HTTP is being considered because it is readily available, supported by many language libraries, and does not need firewall diddling.
As opposed to... TCP? Let's see - TCP is readily available, supported by many language libraries, and has a simple built-in facility (port numbers) that make it easy for a firewall to do its job - that is, accept or reject packets on a per-application basis.
I am not sure why you are using the term "subvert".
Well, I dunno... what's the correct term for "trick the software into letting you do something it was carefully designed to prevent you from doing"? Maybe hack or 0wn?
Can you point out just one meaningful advantage of HTTP over raw TCP as a transport mechanism for any protocol semantically different from "request document" / "submit structured form" / "receive document"? Other than tricking the firewall you are voluntarily running?
Many companies try to use JS+DOM to squeeze GUI-like front-ends from web browsers. Is this "subversion"?
Not really, and it's a lot different from building an actual GUI protocol over HTTP, as we're talking about here. With JS+DOM, HTTP is still being used to serve documents; its use is basically unchanged from the static HTML case. The additional functionality is entirely on the client side. Furthermore, it is a natural extension of the existing functionality of a web browser - remember, the whole point of HTML is to provide information and interactivity, with a user interface controlled entirely on the client side.
IIRC, TCP by itself lacks missing packet management.
Not sure what you mean here. TCP has retransmissions with some very sophisticated backoff strategies. In the face of packet loss, the application never sees missing packets - all it sees is extra delays while TCP takes care of getting the data through.
Now, if your application can tolerate packet loss without consequence (if it makes its own provisions for it, like streaming audio), you generally want UDP rather than TCP, so you don't pay the price in overhead and (especially) latency.
I am not sure which protocol you are referring to, and why it is allegedly bad for GUI's.
He probably meant HTTP. Consider the needs of a GUI:
persistent state over the life of the application instance, which can be hours or days. HTTP, as originally designed, has you open a connection to the server, request a document, possibly send a cookie, get back a document, and close the connection. Persistence, where you keep the same connection open for multiple transactions, wasn't official until HTTP/1.1, and doesn't work well in many situations, such as with proxy servers. Without persistence, the server (application) has no way of sending the client (your display) any updates, such as progress meters or popups, except while the client already has the connection open for its own reason.
low overhead. If the client needs to inform the server that you have moved your mouse 15 pixels to the left and it is now hovering over a different widget than before, it shouldn't have to go to all the trouble of opening a new HTTP connection, encapsulating this data into an HTTP post form or something, sending it to the web server, which then has to dispatch it to your server application. Compare this to the client sending an X11 packet (only a few bytes, for mouse movement) over an open TCP connection with an X app.
low latency. This naturally follows from low overhead.
Sure, it is possible to work around these design conflicts and produce an implementation of an HTTP client and server that have persistence, minimise latency, and do enough stuff client-side to mask the inherent inefficiency of the HTTP spec. But then you've thrown away most of the dubious advantages of starting with HTTP.
And, while I know it is a thrill to work around network administrators because you can't be bothered to go through official channels to make the net work (as Sun would say), I still haven't heard a good reason why a company would condone the use of things like HTTP tunneling to subvert the firewalls the company is paying good money to buy and maintain. Indeed, Randal Schwartz got in major big trouble at Intel a few years ago (as in, he was successfully prosecuted under computer hacking laws!) when he subverted their firewalls with a Perl trick so he could check his email from off-site.
(I guess the lesson is, if you work for or contract for Intel, don't use XML-RPC.)
However, I have seen and heard of a lot of problems getting non-HTTP protocols through firewalls, etc.
I keep hearing this, and it keeps making no sense.
The purpose of a firewall is to keep out undesired network traffic.
The purpose of using (or tunneling through) HTTP is to pass through a firewall without explicit configuration / permission.
If the guy running the firewall thinks your application is secure enough anyway, he'll open up the necessary ports and you won't have to tunnel through HTTP.
Conversely, if your application isn't considered secure enough to open up a firewall port for, isn't it kind of a bad idea to subvert the firewall instead? Doesn't that sort of negate the purpose of having a firewall in the first place?
If the application deployment guy and the firewall guy can't agree on whether to open the firewall port, the company has bigger problems. Somebody needs to be in charge.
In summary, using HTTP for the sole purpose of defeating firewalls is an arms race between two branches of IT. Now, arms races between competitors is what capitalism is all about... but arms races within a company are pointless. You're supposed to be on the same team here! Instead you set up a situation where the app developers and the firewall admins both have to use increasingly sophisticated measures to do their jobs.
And don't give me that "but the firewall guy doesn't know how / can't be bothered to open up ports when we ask for them". That's his job. If nobody at the company has the time or skill to operate a firewall, you may as well not even have one.
I have to conclude that the real purpose of this whole fad of overloading HTTP with things that have nothing to do with HTTP is for deploy unauthorised applications - things the company doesn't know about and hasn't approved.
If IBM would settle on an open HTTP-friendly remote GUI protocol like XWT or SCGUI (my pet protocol), there is no reason the user has to even know it is a mainframe on the other end.
You mean like X11? Yes, XFree86 is fully supported on Linux for S/390. If you truly want a GUI on your server..
Somebody just needs to push a decent remote GUI protocol that works over HTTP.
Now why on earth would you constrain it to work over HTTP? The design requirements of a "decent GUI" are very different from the design goals of HTTP. Or are you one of those inexplicable people who believe "tunneling over HTTP" == "web-enabled" == "good"?
HTTP was never intended for low latency. It was never intended for persistence. It was never intended for asynchronous server->client updates. (Or even client->server updates.) All of these are necessary for a decent GUI protocol. Some of them have been shoehorned into HTTP as time marches on, but I don't, in general, see the point.
If vendors could rework mainframe apps to have a GUI front-end, management would have little reason to switch
Note, though, that the GUI front-end doesn't have to run on the mainframe. Indeed there are quite a few good reasons to run the front-end on a front-end server instead - or even deploy direct to the end-user. This basic architectural principle is called the "client-server model", and it works pretty well.
I've never run into anyone who thought CDE was better than OpenWin
You're talking about the OpenLook interface here, right? Well, you have now met one such person. I detest OpenLook. In contrast, I only mildly dislike Motif.
but that's what was selected as the standard, and that's what Sun provided.
You make it sound like Sun wasn't involved. CDE was actually produced by a 4-way consortium of HP, DEC, Sun and IBM. Thus it is no coincidence that it ships standard with HP-UX, Tru64, Solaris and AIX.
Note that all the way through, applications continued to run with the different desktop managers. Or were you under the impression that different versions of apps were running for different desktop managers?
There are some desktop environment dependencies, though. Obviously there are the accessory applets that transform a window manager into a desktop environment, but I've seen even major applications that require ToolTalk (CDE's equivalent to an ORB, I believe). Features like drag-n-drop and session management are not really standardised between CDE and GNOME, so many applications may need to be patched somewhat to work correctly in both. Then there is the packaging aspects: how and where to specify menu entries / icons / toolbar docks, and how to set up file type associations.
I imagine Sun will run ToolTalk alongside GNOME, and maybe some sort of hybrid customised dual-standard session manager. Presumably there will be some scripts to convert some of the custom stuff in/usr/dt,/etc/dt and ~/.dt over to where GTK+ and GNOME can use it.
Well I'm forced to play my hole card, IPv6 addresses.
Ha! I made drinkypoo play his hole card. I confess I never thought of using a server-class CPU for the embedded market such as routers. Perhaps it will make sense. But that's still not to say 64 bit math is needed in the home market.
Another nice factor of using large integers instead of floating point is that when you absolutely positively have to get the result back in the same number of cycles each time, you can do this.
Uh, no, due to memory caching - and OS interrupts and such - there's very little you can depend on for absolute clock cycle numbers.
Also, you are out of date concerning the 80387. AMD recognised the shortcomings of the 8087, uh, design, so they came out with 3DNow! for a more modern approach to floating point. Intel countered with SSE. I don't know modern x86 assembly but from what I hear, both are a lot pleasanter to work with than 8087 ever was.
The address space will become significant to us all very quickly if we start doing entirely memory-mapped I/O.
That's one of those cases where "a use will be found" if the capability exists. Applications designed for huge data sets seem to have no trouble paging things in and out manually; I imagine there are layers that do this semi-automatically for some languages. A 64-bit CPU and accompanying OS will solve this problem, but it's hardly essential. Now, when the average joe starts getting computers up in the 4GB of memory range (and yes, I can see we're getting there), then it makes sense to have a CPU that can address more than that at a time..
FPU units which can communicate faster over the bus, since they send 1 data word per clock tick, instead of requiring 2 ticks to send 1 word.
Where are you, in 1993? Even the crusty old Pentium has a 64-bit memory bus. Bits of address space / register size are only loosely correlated with memory bandwidth. Granted, the Hammer will have a buttload of both, but keep the issues straight, will ya?
Note that in most circumstances it is just stupid to use 64-bit registers. If your application runs fine with 32-bit quantities, you can save a lot of memory bandwidth - not to mention a lot of memory - by using 32-bit registers.
What's cool about the Hammer is
64-bit integer registers for those (few, in the home market at least) applications that really need them
massive memory and SMP bandwidth for everyone else
not necessarily in that order. (Indeed, "everyone else" will probably only have 1 cpu per box, for that matter.)
Some operations which are basically limited by the number of bytes you can load into a register at a time will happen twice as fast on a 64 bit processor
That's why God created MMX, 3DNow!, SSE and Altivec. They take operations where you are shoving lots of data into a bunch of registers in parallel and doing math on them.
Memory bandwidth is a whole separate issue, and in my opinion that's where the Hammer will really shine, in the home market at least.
64-bit registers will be nice for FEA and other HPC, the big address space will be nice for the business backend, like monster databases... but honestly, even games do fine with the various SIMD extensions found in today's 32-bit consumer CPUs.
All of which is not to say I'm not looking forward to getting me a Hammer.... (:
Does anyone else think that 3.0 should be a microkernel Linux?
If they do, they won't admit it. You're the first one I've heard.
What advantages do you think a microkernel-based Linux would bring? It seems to have thrived for ten years now as a traditional kernel, and although Linux does have its flaws, I can't think of any that a microkernel design would address.
Why did the guy from Oracle ask for LVM? I thought the 2.4 series already had LVM (I'm using it now). From Linus' reply, it seems like there is a new LVM? Anyone have any information about the difference and what the problem with the old one was?
There are / have been three logical volume managers for Linux.
The original LVM by Heinz Mauelschagen (sp?) matured over several years and was in wide use well before Linus dropped it into kernel 2.3.35 or so. Its interface was patterned after the Veritas volume manager as found in HP-UX. Its functionality is similar to the AIX LVM, but somewhat (IBM would say a lot) more limited in scope.
IBM came up with their Enterprise Volume Management System (EVMS) to replace LVM. I think it is partially a port of the AIX LVM, but I'm not sure. The idea was to have a one-stop shop for all your volume management needs, including mirrors, RAID, snapshots, partition management, etc. This is sort of contrary to the Linux philosophy, where we normally layer things - LVM on top of RAID on top of partitions, generally. Thus, EVMS is seen as a lot of code duplication / bloat, but on the other hand it is quite appealing to "enterprise" customers and vendors, due partly to its IBM pedigree I suppose, and partly to the fact that these types of people really go for "integrated solutions".
Finally, Sistina (home of the original LVM hackers) came up with LVM2, which is a complete redesign of LVM - but, unlike EVMS, LVM2 is even more minimalist than LVM1. The kernel component of LVM2 is called Device Mapper, and is a generic way to chop up and paste together your block devices to form logical volumes. The LVM2 user-space code uses the DM interface and implements the rest of the LVM logic on top of it. From a user perspective, LVM2 looks a lot like LVM1.
So everyone agreed that the original LVM1 code, while filling an important gap back in the day, was too ugly to live. Even its creators had abandoned it to twist in the wind when they wrote Device Mapper and the LVM2 corpus. Due to some invasive changes to the entire block device code in Linux 2.5.1 or so, the in-kernel LVM code was left broken, and nobody has been interested in fixing it. It was to be replaced by either EVMS or Device Mapper - or both. Linus left this decision to the last moment, about two days before the feature freeze, when he put in DM and left out EVMS.
EVMS is, as I said, the more feature-rich of the two, but most kernel hackers seemed not to like it very much, due to the aforementioned code duplication and its "all your block devices are belong to us" attitude. Probably, when the Oracle guy asked for LVM, he meant EVMS.
You use LVM1 today. When the 2.6 kernel comes out, you will have to upgrade to LVM2, and compile DM into your kernel, but it should be a smooth upgrade path - your on-disk volume group format will still be supported. Two problems you may face are:
dual-booting between kernels 2.4 and 2.6 - you have to have two sets of LVM tools - there are ways to manage having both installed at once, but I don't know if the distributors will manage this well or not, and
if your root partition is on a logical volume, you need to arrange for it to be activated before mounting, probably with an initrd setup - in which case you'll have to have the LVM2 tools on your initrd instead of the LVM1 tools. Once again your distributor is supposed to handle the problems here but who knows how well they'll do.
You can preempt these problems by patching your 2.4 kernel with Sistina's DM patch, and migrate completely to LVM2/DM while still using 2.4. I'll probably do this the next time I have occasion to reboot, which may not be for awhile (my box has been up for 2.5 months - that's when I overloaded a circuit breaker...).
One last note. You may have heard of the well-publicised note where Kevin Corry announced that EVMS was changing direction. They will now reimplement what is currently a large kernel component of EVMS, moving it out of kernel space into user-space tools that will operate directly on top of Device Mapper (the LVM2 kernel bits). The hope is that DM will prove to be flexible enough that EVMS can continue to exist, with all its current features, purely in user-space - or possibly with a minimal amount of additional kernel code. So, if the Oracle people insist that EVMS is the way Enterprise Systems should run, they should still be satisfied. The EVMS team plans to have the new user-space-based EVMS out in a couple of months, well before 2.6 itself is widely adopted or, indeed, released.
from what I read, it sounds like this attack was not echo requests, but apparently syn packets. Whether they were TCP or UDP and what port is unknown
SYN is specific to TCP - it doesn't exist in UDP. SYN flooding is where you send SYN packets to open a bunch of TCP connections, but then neglect them - forcing the other end to allocate lots of resources to your nonexistent connections, which won't time out for quite awhile. UDP doesn't have the notion of a "connection", so you can't SYN-flood it.
DNS does use TCP for certain longer queries, so it's hard to just turn it off. Now, it may be that the root servers can get away with not using TCP if they don't allow things like zone transfers or other long queries. I dunno, I'm not a DNS expert or anything.
If you skim the <linux-kernel> list for awhile, every now and then some Linux bug'll turn up that has to do with APIC programming, or SMP bus locking cache behavior, or processor flags during NMI, or some such, and even though I don't know much about any of that stuff, I can tell Linus is usually right on top of it. I remember in particular a thread maybe a year or two ago where someone had come up a memory barrier optimisation that could theoretically make a spinlock release op just a teensy bit faster. But then Linus had some misgivings about it because he remembered an erratum for the Pentium Pro where it might reorder memory accesses incorrectly. After a bit of back-and-forth with an Intel guy, they all figured out that the stronger memory barrier was in fact necessary for certain early-stepping PPro chips, so oh well, better luck next time. If I remember correctly, by the end of the discussion I still didn't quite understand the exact memory barrier semantics required by the unlock or the PPro bug in question. (:
One gets the feeling rather quickly that, kernel-in-C or no kernel-in-C, Linus is your guy for low-level implementation of IA32 protected mode.
H. Peter Anvin (also of transmeta) seems quite good at that stuff too, particularly things like chipset and BIOS conventions (and old musty BIOS bugs / misfeatures to watch out for). For instance he seems to actually understand how the A20 gate works, and (more importantly) how to enter PM without tripping any bugs / differences across x86 motherboards. Now how many people in the world of whom you can say that?
However, Transmeta has Christian Ludloff of www.sandpile.org
Well, between the three of them TMTA should be all set. I wouldn't doubt the knowledge of sandpile.org staff either.
I remember that the old Cyrix 6x86 chips didn't emulate the complete x86 instruction set, so many common programs would crash or just plain not run. It seems like transmeta is trying to go the same route, by reverse-engineering Intel's instruction set.
Eh, but I bet there are very few people in the world (outside Intel Corp) that know the IA32 instruction set better than Transmeta's favorite poster boy, Linus. The guy's amazing, as if I had to mention that here. With people like him on board, I bet TMTA can do a pretty good bug-for-bug rendition of a P4. And hey, if not, it's just a firmware update, right?
Actually these days I think chipset issues (OS drivers and hardware bugs) are a lot bigger problem than CPU support. Chipset, mobo and BIOS vendors all seem to have major QA problems and woe to the OS that doesn't work around them all properly.
I just can't take it anymore. Nothing personal - but, you know, all generalisations are false.
These power users fall under Pareto's 20-80 principle: 20% of the users account for 80% of the bandwidth use (and vice versa. Think about it, this rule applies to just about every aspect of life).
Nah, it doesn't. Your 20-80 principle is just a convenient colloquialism for describing any uneven statistical distribution, and then applying it to things that follow a certain distribution. There are plenty of things in life that don't fit it, but you don't notice because you don't think to apply the principle except where it seems to fit.
Do 20% of apples (by count) really account for 80% of apples (by mass)? Answer: no, it's probably a 45-55 principle.
Do 20% of people have 80% of children? No, more like 35%/65% would be my guess.
Are 20% of airlines involved in 80% of accidents? No, a pretty even distribution, unless you lump in commuter services with the big jets.
Do 20% of flowers comprise 80% of the color spectrum variation? No, that's distributed pretty evenly.
Does 20% of the United States get 80% of its rain? Nah, I'm guessing 40%/60% split.
Do 20% of slashdot readers read 80% of the articles? No, slashdot readers always click the links to produce the/. effect but nobody actually reads them - probably 3%/97%.
Do 20% of Microsoft shareholders own 80% of Microsoft stock? No, probably 5%/95%.
In other words, your 20-80 principle only applies to life in general if you're allowed to adjust the split point on a case-by-case basis. Making it a tautology if you know anything about statistics (which, btw, would probably put you ahead of me, but I digress).
The source is included in the package. download it and check it.
Great news, my dear Gurensan, if true.
Unfortunately, it is most probably not true. Please read another post of mine for details. And, if you have information that contradicts that post, please reply!
Slashdot Mirror
In theory? This was like setting a policy that if you sell a gun to an ex-con, it must be sold with the safety catch set. Sure, criminals can "in theory" turn off the safety themselves, but hey, it's better than nothing, right? At least "by default" they can't go out and start shooting people, right?
...Wait. Did you just call Andre's taskfile patch "simple"? Maybe you're one of those people who consider ACPI parsing "simple" too? Have you even read the patch, or was this just hearsay?
For those of you who weren't following along back then, Andre wanted to provide an ioctl-based way to run vendor-specific, often undocumented hard disk commands. This would be things like "make disk read-only" or "unlock extra 10 GB of space the firmware rounded down so they could sell those excess 40GB drives as 30GB" or such. Being vendor-specific and often undocumented commands, the applications that used them might be buggy and, if buggy enough, might be able to turn a hard disk into a paperweight.
The taskfile patch was intended to provide sanity checking in the kernel to guard against buggy applications. Of course, Andre being Andre, he didn't put it that way. By the time he was done yelling, it sounded as though EVIL HACKERS WILL DESTROY YOUR HARD DISKS IN THE BLINK OF AN EYE AND IT'LL BE ALL LINUX'S FAULT. Never mind that the EVIL HACKER already needs to crack root before he gets the necessary raw hard disk access. Never mind that the taskfile patch would not prevent the EVIL HACKER from bypassing the ioctl interface and bit-banging the ATA chip directly. Never mind that, as root, there are a lot of horrible things an EVIL HACKER could do to your system, much more insidious and EVIL than crashing a hard drive, like installing backdoors and making your system fail in subtle ways that you wouldn't notice for a month. Never mind that those same EVIL HACKERS have been able to destroy these same hard disks in any version of Linux or Windows since the beginning of time (well, the beginning of ATA hard disks with these command sets) and yet somehow, remarkably, we haven't yet heard of it being done.
And never mind the whole problem that if a buggy application can destroy your disk, so can a buggy taskfile patch. (Andre tends to exude an abnormally high level of confidence in the quality of his implementations.)
In short, at the risk of sounding like I know what I'm talking about, which I don't really, it was a stupid idea. At least as initially presented on the mailing list. Some time later, the startling revelation came out that the taskfile patch actually had some other uses besides the one listed above (protecting against EVIL HACKERS DESTROYING YOUR HARD DISKS AS YOU SLEEP). And then, marvel of marvels, Linus was suddenly a lot more sympathetic to the patch.
And that, at the risk of sounding like one of your alleged arrogant pricks on linux-kernel, is idiotic too. Hard to explain what's so utterly wrong with your statement - I guess it's just one of those things - if you have to ask, you'll never know. (Now how's that for elitist?...)
C'mon, nobody with any net.savvy has to Google to figure out who Brad Templeton is.
So what do you type when M-x c-set-style asks you to pick a style? (:
Your choices, btw, are: "bsd", "cc-mode", "ellemtel", "gnu", "java", "k&r", "linux", "python", "stroustrup", "user", and "whitesmith". Many of these are only subtly different from each other - frex, "linux" is basically "k&r" with an 8-space basic offset.
That's why these styles need actual names - you can just blame it all on Emacs. (:
Heh. I love that word. It always reminds me of a Don Chaffer song. He's making fun of people who spout psychobabble:
I love that, it's so Ogden Nash..
Very good point. The opt-in mail should be sent priority 'bulk' meaning it's a form letter - perhaps that will prevent these vacation programs from auto-replying. But you're right, it's far from certain.
That would work. Or something like "simply reply to this message, quoting this text, but add the word CONFIRM to the subject line."
Remember the original meaning of the word daemon - maybe you do have one in your mail system somewhere, and it does have a penis, and wants a bigger one.
#include <ianal.txt>
Technically it is not illegal to use mplayer to watch your DVD - at least, assuming nobody has a patent on the various bits of MPEG2 contained therein. (Because mplayer doesn't have the appropriate patent licenses. Although, if you own a copy of Quicktime or WMP, you probably have such a patent license, in which case you're fine. And since both QT and WMP are free downloads, you can thus acquire a patent license quite easily just by downloading the executables.)
But it is a DMCA violation to distribute mplayer. So those Hungarians are in big trouble, as are you if you put it up for your friends to download.
Of course, that is relying on the pedantic, literal interpretation of the DMCA. And we all know how far that goes when Adobe picks up the phone and sics the FBI on you.
Are you talking about snail mail or email opt-in? For email opt-in, it's pretty easy. You send the subscribee a confirmation mail containing a random number string, and if they send it back (just hit 'reply' and quote the whole thing) they're confirmed.
The only way to spoof this is to gain access to the victim's mailbox, so you can receive the confirmation mail with the random number in it. And if you have access to the victim's mailbox (or a router in between, etc) there is nothing that can prevent opt-in spoofing, short of everyone having pgp or some other pki, with a web of trust spanning the whole world. Like that's ever gonna happen.
You sure about that? Even the original ISA-based IDE interface has two separate port ranges and two IRQs for the two channels. That to me implies that you can treat them as independent interfaces. If both channels are handled by a single chip which is limited to a single command at a time, that is a mere implementation detail.
I seriously doubt the SATA specs tie the hands of the hardware people in such a way as to forbid multiple ports to be treated as independent entities. (Especially now, with PCI being all the rage - PCI has a provision for providing multiple independent "functions" per bus address - that is, per PCI card or per motherboard chip.) If there is such a limitation, I expect it only affects the old ISA IDE compatibility mode (i.e. what your OS uses if it doesn't have a specific driver for the SATA chip in question).
If you have good information to the contrary, I shall have to accept it, but I'll be surprised.
Hmm. Bug in the Promise design, then. Serial ATA is designed for "one cable, one device" (no more master/slave) but different cables - aka different channels - should run just fine in parallel.
Actually, it may not be a design bug, but a driver limitation. Who knows - I don't have your card. It's not a shortcoming of the SATA spec, though.
As opposed to ... TCP? Let's see - TCP is readily available, supported by many language libraries, and has a simple built-in facility (port numbers) that make it easy for a firewall to do its job - that is, accept or reject packets on a per-application basis.
Well, I dunno ... what's the correct term for "trick the software into letting you do something it was carefully designed to prevent you from doing"? Maybe hack or 0wn?
Can you point out just one meaningful advantage of HTTP over raw TCP as a transport mechanism for any protocol semantically different from "request document" / "submit structured form" / "receive document"? Other than tricking the firewall you are voluntarily running?
Not really, and it's a lot different from building an actual GUI protocol over HTTP, as we're talking about here. With JS+DOM, HTTP is still being used to serve documents; its use is basically unchanged from the static HTML case. The additional functionality is entirely on the client side. Furthermore, it is a natural extension of the existing functionality of a web browser - remember, the whole point of HTML is to provide information and interactivity, with a user interface controlled entirely on the client side.
Not sure what you mean here. TCP has retransmissions with some very sophisticated backoff strategies. In the face of packet loss, the application never sees missing packets - all it sees is extra delays while TCP takes care of getting the data through.
Now, if your application can tolerate packet loss without consequence (if it makes its own provisions for it, like streaming audio), you generally want UDP rather than TCP, so you don't pay the price in overhead and (especially) latency.
He probably meant HTTP. Consider the needs of a GUI:
Sure, it is possible to work around these design conflicts and produce an implementation of an HTTP client and server that have persistence, minimise latency, and do enough stuff client-side to mask the inherent inefficiency of the HTTP spec. But then you've thrown away most of the dubious advantages of starting with HTTP.
And, while I know it is a thrill to work around network administrators because you can't be bothered to go through official channels to make the net work (as Sun would say), I still haven't heard a good reason why a company would condone the use of things like HTTP tunneling to subvert the firewalls the company is paying good money to buy and maintain. Indeed, Randal Schwartz got in major big trouble at Intel a few years ago (as in, he was successfully prosecuted under computer hacking laws!) when he subverted their firewalls with a Perl trick so he could check his email from off-site.
(I guess the lesson is, if you work for or contract for Intel, don't use XML-RPC.)
I keep hearing this, and it keeps making no sense.
If the application deployment guy and the firewall guy can't agree on whether to open the firewall port, the company has bigger problems. Somebody needs to be in charge.
In summary, using HTTP for the sole purpose of defeating firewalls is an arms race between two branches of IT. Now, arms races between competitors is what capitalism is all about ... but arms races within a company are pointless. You're supposed to be on the same team here! Instead you set up a situation where the app developers and the firewall admins both have to use increasingly sophisticated measures to do their jobs.
And don't give me that "but the firewall guy doesn't know how / can't be bothered to open up ports when we ask for them". That's his job. If nobody at the company has the time or skill to operate a firewall, you may as well not even have one.
I have to conclude that the real purpose of this whole fad of overloading HTTP with things that have nothing to do with HTTP is for deploy unauthorised applications - things the company doesn't know about and hasn't approved.
You mean like X11? Yes, XFree86 is fully supported on Linux for S/390. If you truly want a GUI on your server..
Now why on earth would you constrain it to work over HTTP? The design requirements of a "decent GUI" are very different from the design goals of HTTP. Or are you one of those inexplicable people who believe "tunneling over HTTP" == "web-enabled" == "good"?
HTTP was never intended for low latency. It was never intended for persistence. It was never intended for asynchronous server->client updates. (Or even client->server updates.) All of these are necessary for a decent GUI protocol. Some of them have been shoehorned into HTTP as time marches on, but I don't, in general, see the point.
Note, though, that the GUI front-end doesn't have to run on the mainframe. Indeed there are quite a few good reasons to run the front-end on a front-end server instead - or even deploy direct to the end-user. This basic architectural principle is called the "client-server model", and it works pretty well.
You're talking about the OpenLook interface here, right? Well, you have now met one such person. I detest OpenLook. In contrast, I only mildly dislike Motif.
You make it sound like Sun wasn't involved. CDE was actually produced by a 4-way consortium of HP, DEC, Sun and IBM. Thus it is no coincidence that it ships standard with HP-UX, Tru64, Solaris and AIX.
There are some desktop environment dependencies, though. Obviously there are the accessory applets that transform a window manager into a desktop environment, but I've seen even major applications that require ToolTalk (CDE's equivalent to an ORB, I believe). Features like drag-n-drop and session management are not really standardised between CDE and GNOME, so many applications may need to be patched somewhat to work correctly in both. Then there is the packaging aspects: how and where to specify menu entries / icons / toolbar docks, and how to set up file type associations.
I imagine Sun will run ToolTalk alongside GNOME, and maybe some sort of hybrid customised dual-standard session manager. Presumably there will be some scripts to convert some of the custom stuff in /usr/dt, /etc/dt and ~/.dt over to where GTK+ and GNOME can use it.
Ha! I made drinkypoo play his hole card. I confess I never thought of using a server-class CPU for the embedded market such as routers. Perhaps it will make sense. But that's still not to say 64 bit math is needed in the home market.
Uh, no, due to memory caching - and OS interrupts and such - there's very little you can depend on for absolute clock cycle numbers.
Also, you are out of date concerning the 80387. AMD recognised the shortcomings of the 8087, uh, design, so they came out with 3DNow! for a more modern approach to floating point. Intel countered with SSE. I don't know modern x86 assembly but from what I hear, both are a lot pleasanter to work with than 8087 ever was.
That's one of those cases where "a use will be found" if the capability exists. Applications designed for huge data sets seem to have no trouble paging things in and out manually; I imagine there are layers that do this semi-automatically for some languages. A 64-bit CPU and accompanying OS will solve this problem, but it's hardly essential. Now, when the average joe starts getting computers up in the 4GB of memory range (and yes, I can see we're getting there), then it makes sense to have a CPU that can address more than that at a time..
Where are you, in 1993? Even the crusty old Pentium has a 64-bit memory bus. Bits of address space / register size are only loosely correlated with memory bandwidth. Granted, the Hammer will have a buttload of both, but keep the issues straight, will ya?
Note that in most circumstances it is just stupid to use 64-bit registers. If your application runs fine with 32-bit quantities, you can save a lot of memory bandwidth - not to mention a lot of memory - by using 32-bit registers.
What's cool about the Hammer is
- 64-bit integer registers for those (few, in the home market at least) applications that really need them
- massive memory and SMP bandwidth for everyone else
not necessarily in that order. (Indeed, "everyone else" will probably only have 1 cpu per box, for that matter.)That's why God created MMX, 3DNow!, SSE and Altivec. They take operations where you are shoving lots of data into a bunch of registers in parallel and doing math on them.
Memory bandwidth is a whole separate issue, and in my opinion that's where the Hammer will really shine, in the home market at least.
64-bit registers will be nice for FEA and other HPC, the big address space will be nice for the business backend, like monster databases ... but honestly, even games do fine with the various SIMD extensions found in today's 32-bit consumer CPUs.
All of which is not to say I'm not looking forward to getting me a Hammer.... (:
The French expression à la has a grave accent, too.
</meta-nitpick>
If they do, they won't admit it. You're the first one I've heard.
What advantages do you think a microkernel-based Linux would bring? It seems to have thrived for ten years now as a traditional kernel, and although Linux does have its flaws, I can't think of any that a microkernel design would address.
There are / have been three logical volume managers for Linux.
So everyone agreed that the original LVM1 code, while filling an important gap back in the day, was too ugly to live. Even its creators had abandoned it to twist in the wind when they wrote Device Mapper and the LVM2 corpus. Due to some invasive changes to the entire block device code in Linux 2.5.1 or so, the in-kernel LVM code was left broken, and nobody has been interested in fixing it. It was to be replaced by either EVMS or Device Mapper - or both. Linus left this decision to the last moment, about two days before the feature freeze, when he put in DM and left out EVMS.
EVMS is, as I said, the more feature-rich of the two, but most kernel hackers seemed not to like it very much, due to the aforementioned code duplication and its "all your block devices are belong to us" attitude. Probably, when the Oracle guy asked for LVM, he meant EVMS.
You use LVM1 today. When the 2.6 kernel comes out, you will have to upgrade to LVM2, and compile DM into your kernel, but it should be a smooth upgrade path - your on-disk volume group format will still be supported. Two problems you may face are:
You can preempt these problems by patching your 2.4 kernel with Sistina's DM patch, and migrate completely to LVM2/DM while still using 2.4. I'll probably do this the next time I have occasion to reboot, which may not be for awhile (my box has been up for 2.5 months - that's when I overloaded a circuit breaker...).
One last note. You may have heard of the well-publicised note where Kevin Corry announced that EVMS was changing direction. They will now reimplement what is currently a large kernel component of EVMS, moving it out of kernel space into user-space tools that will operate directly on top of Device Mapper (the LVM2 kernel bits). The hope is that DM will prove to be flexible enough that EVMS can continue to exist, with all its current features, purely in user-space - or possibly with a minimal amount of additional kernel code. So, if the Oracle people insist that EVMS is the way Enterprise Systems should run, they should still be satisfied. The EVMS team plans to have the new user-space-based EVMS out in a couple of months, well before 2.6 itself is widely adopted or, indeed, released.
SYN is specific to TCP - it doesn't exist in UDP. SYN flooding is where you send SYN packets to open a bunch of TCP connections, but then neglect them - forcing the other end to allocate lots of resources to your nonexistent connections, which won't time out for quite awhile. UDP doesn't have the notion of a "connection", so you can't SYN-flood it.
DNS does use TCP for certain longer queries, so it's hard to just turn it off. Now, it may be that the root servers can get away with not using TCP if they don't allow things like zone transfers or other long queries. I dunno, I'm not a DNS expert or anything.
Well, I doubt you know that much about Linus. (:
If you skim the <linux-kernel> list for awhile, every now and then some Linux bug'll turn up that has to do with APIC programming, or SMP bus locking cache behavior, or processor flags during NMI, or some such, and even though I don't know much about any of that stuff, I can tell Linus is usually right on top of it. I remember in particular a thread maybe a year or two ago where someone had come up a memory barrier optimisation that could theoretically make a spinlock release op just a teensy bit faster. But then Linus had some misgivings about it because he remembered an erratum for the Pentium Pro where it might reorder memory accesses incorrectly. After a bit of back-and-forth with an Intel guy, they all figured out that the stronger memory barrier was in fact necessary for certain early-stepping PPro chips, so oh well, better luck next time. If I remember correctly, by the end of the discussion I still didn't quite understand the exact memory barrier semantics required by the unlock or the PPro bug in question. (:
One gets the feeling rather quickly that, kernel-in-C or no kernel-in-C, Linus is your guy for low-level implementation of IA32 protected mode.
H. Peter Anvin (also of transmeta) seems quite good at that stuff too, particularly things like chipset and BIOS conventions (and old musty BIOS bugs / misfeatures to watch out for). For instance he seems to actually understand how the A20 gate works, and (more importantly) how to enter PM without tripping any bugs / differences across x86 motherboards. Now how many people in the world of whom you can say that?
Well, between the three of them TMTA should be all set. I wouldn't doubt the knowledge of sandpile.org staff either.
Eh, but I bet there are very few people in the world (outside Intel Corp) that know the IA32 instruction set better than Transmeta's favorite poster boy, Linus. The guy's amazing, as if I had to mention that here. With people like him on board, I bet TMTA can do a pretty good bug-for-bug rendition of a P4. And hey, if not, it's just a firmware update, right?
Actually these days I think chipset issues (OS drivers and hardware bugs) are a lot bigger problem than CPU support. Chipset, mobo and BIOS vendors all seem to have major QA problems and woe to the OS that doesn't work around them all properly.
I just can't take it anymore. Nothing personal - but, you know, all generalisations are false.
Nah, it doesn't. Your 20-80 principle is just a convenient colloquialism for describing any uneven statistical distribution, and then applying it to things that follow a certain distribution. There are plenty of things in life that don't fit it, but you don't notice because you don't think to apply the principle except where it seems to fit.
In other words, your 20-80 principle only applies to life in general if you're allowed to adjust the split point on a case-by-case basis. Making it a tautology if you know anything about statistics (which, btw, would probably put you ahead of me, but I digress).
Great news, my dear Gurensan, if true.
Unfortunately, it is most probably not true. Please read another post of mine for details. And, if you have information that contradicts that post, please reply!