Because we are still using (on x86) a CPU that, when it powers up, emulates a CPU that was designed 20 years ago. So your peripherals have to have options ROMs that expect an operating environment that is similar to 20 years ago.
If someone can get every BIOS maker, motherboard maker, video card maker, SCSI card maker and network card maker to all simultaneously (a) switch to a different pre-boot environment, or (b) include code for both the existing AT-style pre-boot as well as a hypothetical newer environment; escaping the AT-style POST environment won't happen.
If the corporate face is attached to the item, do you really think that they're going to be as even-handed about it as you think? If the bottom line could be at stake, which goes first, the blog, or the rest of the entire company?
If even the *perception* of trouble comes up attached to the H.P. name, do you think that H.P., or any other company, is going to not do preemptive damage control?
Dividing up a task into reasonably-sized pieces along *well-delineated* and *sensible* boundaries is usually important to a program of any size at all if is to be maintainable in the future. Option #1 looks suspiciously like this idea, and is probably fundamental to a project of any size that can afford the time this takes.
Microsoft, long ago, felt it had a stake in reshaping the nature of browsers. Personally, I don't think the GNU C Compiler folks feel they have a stake in reshaping the nature of compilers.
This issue is going to happen on Gentoo because of how devfsd's configuration is built.
Actually, something similar could conceivably go wrong with/etc/profile.d and/etc/env.d. A coding change on "etc-update" would probably solve the/etc/devfsd.d screwup.
Short answer: IP address blocks are more like roads, cities and states than phone numbers. That is, the customer, in effect, has been granted a temporary court order allowing him to force his old house in Wyoming to have the same street address, state and zip code when he flatbeds it with him to Alaska.
Longer answer: The reason IP address blocks are like streets, cities and states is because the blocks are a "fundamental" address for routing internet packets. All transit routers (e.g. non-edge, non-private-service) *HAVE* to know which router can reach *EACH AND EVERY ONE* of the existing large blocks. This is the same as how all postal office workers need to understand that Oklahoma borders Texas.
(Aside: Yes, I'm oversimplifying; the tech (eBGP/OSPF/whatever) isn't germane to this overview.)
Each "AS" (Autonomous System, among other things an entity that manages keeping track of both which IP block(s) they have but also which IP block(s) are network-adjacent to their blocks) must cooperate in order to keep the mappings straight. This is very hard even with registered number authorities (ARIN, RIPE, APNIC) in existence.
Phone numbers have not been a "fundamental addressing" for many many years in the United States telephone system. A while ago, they used to be, which was one reason you couldn't take you phone number with you if you moved out of an area code. An incremental redesigning of carrier's internals now make any phone number in the US a "virtual" number. Yes folks, phone numbers have been like DNS lookups for years now.
So, eventually, *maybe*, the internet can be reengineered to operate with fully portable IP addresses. It's just not a good idea *right now*.
BTW, nice troll Mr. Senator:)
(off-topic) Re:Grudgingly going back to Sendmail.
on
Postfix 2.1 Released
·
· Score: 1
In my neck of the woods, spammer-built SMTP engines tend to target all the listed MXes. Especially when the customer (grumble) has employees who actually sign up for stuff with their real e-mail addresses.
I'm afraid SASL authentication is pretty much still just as goofy as previously. Once one understands just where SASL ended up on a given system, it's straightforward.
As I hinted, the problem revolves around just where SASL is installed. Unless you installed from tarballs, your vendor's SASL probably has SASL-related files in different places. Tracking them down (as well as knowing what lives in which directory) is a pain.
Just because we're OSS advocates doesn't mean we stopped being human beings. Users didn't stop being human beings either. That's why they're still Lazy, Stupid and Horny (to paraphrase Scott Adams), and therefore capable of making other people miserable.
I imagine that the post which is parent to this is referring to all users, not specifically ESR.
I do computer support consulting. Sometimes it's amazing what people don't know about the tools they're using every day (say, the Outlook Express preview pane).
Show me a document that shows provably that Microsoft will supply an option to have an OS-level trust model other than their own BY DEFAULT with every TCPA-aware OS they will ship.
The linked papers show the theory. 90% market share shows the likely practice.
CPU-ID was absolutely nothing *because* people screamed about it. BIOS vendors the world over included the kill-switch, and OS vendors were smart enough to avoid being publicly caught making any use of the data.
The difference here is that the OS vendor is *insisting* on making it be so. By analogy, Intel was just one country's leader in the UN who got his policies changed by public demand. Contrast here, where Microsoft wants to be Ozymandias, King of Kings. And there's time to stop it from being so but only when enough people realize how its backers want to use it.
I know this stuff is dense, but I happen to think it's stuff that any serious Linux admin should know about eventually, so I spread the word. If you want some pointers on where to start, send me an IM. I'll be at work all day today more-or-less.
We attached ClamAV on several CommuniGate Pro mail servers using CGPAV to glue the two together. Apart from the current wave of password-protected-ZIP files, it seems to have been quite effective. Updates seem to be ready at least daily as far as I can see. Disclaimer: it has only been in place some 3-4 weeks now.
Bad sides? Spartan documentation. Nothing a competent admin can't work out.
Take this as subjective experience; ClamAV has no way to tell me it allowed a virus through. And circumstances make it infeasible for me to put a commercial scanner behind it to let me know what it missed.
That would probably because it's been laid in the wrong places and doesn't connect to enough profitable endpoints. Which makes it about as useful as the proverbial solar-powered flashlight.
Nutz. Slash ate the link because I am a moron. The link is: [http://www-106.ibm.com/developerworks/library/wa- objprev/]; referenced by the original Slashdot article.
Y'all may want to take a look at for some better (even better than the Prevayler website) information on the problem space that Prevayler is good for.
It seems to me (in agreement with every commentor who has mentioned that this parent (Slashdot) article's title is misleading and inappropriate) that Prevayler's strength is in making it easy to persist *business objects*, not do away with the RDBMS entirely. If you've a strategy that involves tabular data as well as objects, and doesn't absolutely require a closer-than-reference coupling of the two, then Prevayler might help you out. Particularly if the business objects mutate very often during runtime.
I can envision, for example, raw data stuck in normalized tables in an RDBMS, with the *roll-ups* stored in Prevayler objects persisted elsewise.
As a software engineering protocol, "open source" appears to be remarkably ineffective.
Question being: ineffective for whom?
If a person likes fooling around and spending his time that way, then yeah: he's performing mental masturbation. Maybe that's all he wanted. Maybe scratching his itch, with the expectation that someone else will be helped, hadn't even crossed the coder's mind.
I am using my experience at a particular client site where I am consulting. Utilizes a VB client application to track persistent inventory (i.e. a resource that isn't used up permanently, such as seats on an airliner) versus inventory reservations (e.g. someone books a flight, gets seat 8A in first class, etc.).
My observation is that a Java/Swing version would force front-loading of the work, and would penalize a crappy design much, much sooner than a VB implementation.
It's just that once you run into something the VB toolset doesn't let your app do, you realize that you have to rip a whole lot of stuff out.
6-7 months old. I fell from a bookshelf after climbing to its top under my own power (yeah, I was mobile *really* early).
I don't really remember the climb well. I remember the top face of a table, a family heirloom. Made of this wood which stained to jet black, with mother-of-pearl inlays on it. There was this glass plate which was always laid on top of the table itself in order to protect it. I remember this "redness", a blotch, spreading around the top of the glass, making the inlays underneath go reddish. This is my first visual memory.
It might be that I remember this because it necessitated a trip to the emergency room to deal with a severe impact trauma to my forehead, sustained when I fell approximately 5 feet head-first on the corner of a steel filing cabinet.
As time went on, I managed to cause even more trouble. Usually didn't hurt myself as badly though:P
Slashdot Mirror
Because we are still using (on x86) a CPU that, when it powers up, emulates a CPU that was designed 20 years ago. So your peripherals have to have options ROMs that expect an operating environment that is similar to 20 years ago.
If someone can get every BIOS maker, motherboard maker, video card maker, SCSI card maker and network card maker to all simultaneously (a) switch to a different pre-boot environment, or (b) include code for both the existing AT-style pre-boot as well as a hypothetical newer environment; escaping the AT-style POST environment won't happen.
If the corporate face is attached to the item, do you really think that they're going to be as even-handed about it as you think? If the bottom line could be at stake, which goes first, the blog, or the rest of the entire company?
If even the *perception* of trouble comes up attached to the H.P. name, do you think that H.P., or any other company, is going to not do preemptive damage control?
Make a point to remember in the future that we're scratching our own itches, and not everyone is interesting in Saving The World through Linux.
Dividing up a task into reasonably-sized pieces along *well-delineated* and *sensible* boundaries is usually important to a program of any size at all if is to be maintainable in the future. Option #1 looks suspiciously like this idea, and is probably fundamental to a project of any size that can afford the time this takes.
Microsoft, long ago, felt it had a stake in reshaping the nature of browsers. Personally, I don't think the GNU C Compiler folks feel they have a stake in reshaping the nature of compilers.
This issue is going to happen on Gentoo because of how devfsd's configuration is built.
/etc/profile.d and /etc/env.d. A coding change on "etc-update" would probably solve the /etc/devfsd.d screwup.
Actually, something similar could conceivably go wrong with
Here you go:
:)
Short answer: IP address blocks are more like roads, cities and states than phone numbers. That is, the customer, in effect, has been granted a temporary court order allowing him to force his old house in Wyoming to have the same street address, state and zip code when he flatbeds it with him to Alaska.
Longer answer: The reason IP address blocks are like streets, cities and states is because the blocks are a "fundamental" address for routing internet packets. All transit routers (e.g. non-edge, non-private-service) *HAVE* to know which router can reach *EACH AND EVERY ONE* of the existing large blocks. This is the same as how all postal office workers need to understand that Oklahoma borders Texas.
(Aside: Yes, I'm oversimplifying; the tech (eBGP/OSPF/whatever) isn't germane to this overview.)
Each "AS" (Autonomous System, among other things an entity that manages keeping track of both which IP block(s) they have but also which IP block(s) are network-adjacent to their blocks) must cooperate in order to keep the mappings straight. This is very hard even with registered number authorities (ARIN, RIPE, APNIC) in existence.
Phone numbers have not been a "fundamental addressing" for many many years in the United States telephone system. A while ago, they used to be, which was one reason you couldn't take you phone number with you if you moved out of an area code. An incremental redesigning of carrier's internals now make any phone number in the US a "virtual" number. Yes folks, phone numbers have been like DNS lookups for years now.
So, eventually, *maybe*, the internet can be reengineered to operate with fully portable IP addresses. It's just not a good idea *right now*.
BTW, nice troll Mr. Senator
In my neck of the woods, spammer-built SMTP engines tend to target all the listed MXes. Especially when the customer (grumble) has employees who actually sign up for stuff with their real e-mail addresses.
I'm afraid SASL authentication is pretty much still just as goofy as previously. Once one understands just where SASL ended up on a given system, it's straightforward.
As I hinted, the problem revolves around just where SASL is installed. Unless you installed from tarballs, your vendor's SASL probably has SASL-related files in different places. Tracking them down (as well as knowing what lives in which directory) is a pain.
We *are* infighting children.
Just because we're OSS advocates doesn't mean we stopped being human beings. Users didn't stop being human beings either. That's why they're still Lazy, Stupid and Horny (to paraphrase Scott Adams), and therefore capable of making other people miserable.
"Procmail"
I imagine that the post which is parent to this is referring to all users, not specifically ESR.
I do computer support consulting. Sometimes it's amazing what people don't know about the tools they're using every day (say, the Outlook Express preview pane).
Show me a document that shows provably that Microsoft will supply an option to have an OS-level trust model other than their own BY DEFAULT with every TCPA-aware OS they will ship.
The linked papers show the theory. 90% market share shows the likely practice.
CPU-ID was absolutely nothing *because* people screamed about it. BIOS vendors the world over included the kill-switch, and OS vendors were smart enough to avoid being publicly caught making any use of the data.
The difference here is that the OS vendor is *insisting* on making it be so. By analogy, Intel was just one country's leader in the UN who got his policies changed by public demand. Contrast here, where Microsoft wants to be Ozymandias, King of Kings. And there's time to stop it from being so but only when enough people realize how its backers want to use it.
Time to let your fingers do the walking...
Linux Advanced Routing and Traffic Control
I know this stuff is dense, but I happen to think it's stuff that any serious Linux admin should know about eventually, so I spread the word. If you want some pointers on where to start, send me an IM. I'll be at work all day today more-or-less.
We attached ClamAV on several CommuniGate Pro mail servers using CGPAV to glue the two together. Apart from the current wave of password-protected-ZIP files, it seems to have been quite effective. Updates seem to be ready at least daily as far as I can see. Disclaimer: it has only been in place some 3-4 weeks now.
Bad sides? Spartan documentation. Nothing a competent admin can't work out.
Take this as subjective experience; ClamAV has no way to tell me it allowed a virus through. And circumstances make it infeasible for me to put a commercial scanner behind it to let me know what it missed.
That would probably because it's been laid in the wrong places and doesn't connect to enough profitable endpoints. Which makes it about as useful as the proverbial solar-powered flashlight.
Seems like it's time to have the title changed, or a note from the editors indicating that Perens LLC != UnitedLinux.
Nutz. Slash ate the link because I am a moron. The link is: [http://www-106.ibm.com/developerworks/library/wa- objprev/]; referenced by the original Slashdot article.
Y'all may want to take a look at for some better (even better than the Prevayler website) information on the problem space that Prevayler is good for.
It seems to me (in agreement with every commentor who has mentioned that this parent (Slashdot) article's title is misleading and inappropriate) that Prevayler's strength is in making it easy to persist *business objects*, not do away with the RDBMS entirely. If you've a strategy that involves tabular data as well as objects, and doesn't absolutely require a closer-than-reference coupling of the two, then Prevayler might help you out. Particularly if the business objects mutate very often during runtime.
I can envision, for example, raw data stuck in normalized tables in an RDBMS, with the *roll-ups* stored in Prevayler objects persisted elsewise.
Arguably, this announcement *is* the result of an increase in code vetting on the part of the portable OpenSSH team. Just a thought.
It is possible to refuse the update, but it is not possible for the sidekick to bother you less often than every day.
I think the opinion-point in your argument is:
As a software engineering protocol, "open source" appears to be remarkably ineffective.
Question being: ineffective for whom?
If a person likes fooling around and spending his time that way, then yeah: he's performing mental masturbation. Maybe that's all he wanted. Maybe scratching his itch, with the expectation that someone else will be helped, hadn't even crossed the coder's mind.
I am using my experience at a particular client site where I am consulting. Utilizes a VB client application to track persistent inventory (i.e. a resource that isn't used up permanently, such as seats on an airliner) versus inventory reservations (e.g. someone books a flight, gets seat 8A in first class, etc.).
My observation is that a Java/Swing version would force front-loading of the work, and would penalize a crappy design much, much sooner than a VB implementation.
It's just that once you run into something the VB toolset doesn't let your app do, you realize that you have to rip a whole lot of stuff out.
Lots of anomalies in this one:
:P
6-7 months old. I fell from a bookshelf after climbing to its top under my own power (yeah, I was mobile *really* early).
I don't really remember the climb well. I remember the top face of a table, a family heirloom. Made of this wood which stained to jet black, with mother-of-pearl inlays on it. There was this glass plate which was always laid on top of the table itself in order to protect it. I remember this "redness", a blotch, spreading around the top of the glass, making the inlays underneath go reddish. This is my first visual memory.
It might be that I remember this because it necessitated a trip to the emergency room to deal with a severe impact trauma to my forehead, sustained when I fell approximately 5 feet head-first on the corner of a steel filing cabinet.
As time went on, I managed to cause even more trouble. Usually didn't hurt myself as badly though