Sun One, formerly iPlanet? We made that mistake, too. We'd used Netscape's Apache port previously, when we had customers who wanted a commercial webserver for some odd reason, so when that went to iPlanet, we followed. Oh my god, was that painful.
Reminded me of what happened to SCO UNIX. Xenix, in the '80s, was actually a pretty solid small-office OS. Then they started adding stuff to it, redid it using System V and kept everything they already had. So now you had two sets of drivers and configuration. Repeat a few more times with SCO UNIX and SCO Openserver and SCO UNIXware, and pretty soon you needed the curses then X11 config tools because the stuff underneath was so damn complex there was no way to figure out WTF went where.
Windows is like that, too, but nobody but Microsoft is expected to know how far the turtles go down so people put up with it.
Clarifying one point: When the daemon is started, it does a pass over any files on the watch list and updates their info.
I don't mean that it only checks files on the watch list when it starts, I mean that when it starts it does an extra exhaustive pass over the watch-list to catch any files that may have been open when it was previously terminated. In normal use it would check when the file was closed or when it had been open longer than whatever the daemon's update window was.
I assumed you were misinformed about those issue because of your continued insistence that the technology is file system specific, and that kernel notifications offer potential improvement.
you appeared to be claiming that it will only work at all on hfs volumes
Crikey. Go back and read what I actually wrote. Can you see where I already referred to software (glimpse, harvest) that does a similar thing using exhaustive traversal of the file system? So claiming that I've said that you can't do the same thing without a hook like this (either the one Apple's using, or a notification scheme) seems pretty damned weird to me. What I said was that you couldn't do it efficiently:
it is not file system specific in the first place
Since the overhead of exhaustive traversal is simply prohibitive, unless you're going to be satisfied by a database that's hours or days out of date. Being hours out of date is fine for something like Google, but for Spotlight it's a killer. You need a better mechanism to keep it both fast and efficient enough for this application, and the one Spotlight is using is file-system specific.
(I've actually tried variations on this using both Harvest and my own software, and the amount of filesystem activity you need to stay within a shorter window, on any reasonably sized filesystem, is horrible)
You assert that notifications need only be sent when mtime changes, not for each file system write. This does not make sense.
Actually, THAT part makes sense. Apparently the mechanism I assumed I could use for efficiently detecting that isn't there, but that doesn't mean that the only alternative is to put a kqueue call in the critical path of block writes.
Here's another mechanism that would work:
Track the VOPs that I already listed, plus OPEN and CLOSE. When the daemon sees an OPEN for write or modify, that file goes on a watch list. When the daemon sees a close, the file goes off the list. When the daemon is started, it does a pass over any files on the watch list and updates their info.
This isn't as good as getting mtime notifications, because it's got to dynamically monitor files it could have passively monitored before. But next to an exhaustive traversal it's incomparably better.
What will they do when stick-on wireless webcams and scriptable flashcams cost about the same as those cheap digital watches they give away as prizes in happy meals?
THIS WAR IS LOST, you better welcome the transparent society or prepare for a police state.
But with 99% global cooperation, wouldnt this solution provide additional accuracy for existing spam filters?
With 99% global cooperation we could stop spam in a year any number of ways that would be easier and less damaging than adding layers of criplling checks to every SMTP transaction.
The reason we need technological aids to fight spam is simply because we can't get anything like that. It took years of hard work and real effective blacklisting by RBLs just to get as much cooperation as we currently have. Getting 99% of ISPs or even getting the ISPs responsible for 99% of the global market to agree on things as simple as blocking port 25 for dial-up users... let alone cooperating in something like this... is science fiction.
This is precisely the form of spam that will be impossible under domain keys.
Only if DomainKeys are universally supported for all such cases. And ISPs are willing to let their own customers register when it's appropriate.
I mean, we can already block dynamic addresses through an RBL pretty reliably, and since you're assuming enough ISPs go along to make it worthwhile you might as well assume they would self-RBL their own dynamic space and make it absolutely accurate.
And they haven't, in general.
This may help, though I'm not at all convinced that it'll be as effective as an RBL and they don't even make an order of magnitude difference in the spam level. To really have an impact on spammers, you need at least three nines coverage and you need to keep the spammers from working around it, or they'll just concentrate in the part of the net that's not served by cooperative ISPs... and that's an awful lot of it.
Linux is effectively under a license more like the LGPL, since Linus allows companies to distribute drivers without GPLing them. So it seems, at least, to share the attributes of the LGPL that would make it compatible with almost all FOSS licenses so long as components under other licenses are distributed as loadable modules.
whats really needed is a CPU intensive solution like the hashcash suggestion
Which kills legitimate mailing lists.
There's one way to prevent spam and that's to make it a lot more expensive in human time to send unsolicited bulk email. There's no way to do this, though, without making it a little more expensive in human time to send single messages, or to sign up to a mailing list.
I've been using it for my family's mail for the past few years and so far as I know a total of one Nigerian has decided it's worth their time to jump through the hoop to get in.
The problem with this is that people who haven't yet accepted that spam can't be solved without making mail a little harder to use aren't willing to jump through any hoops, and that most people running mailing lists aren't yet set up to give people the necessary information to whitelist them.
There's a bunch of different mechanisms that can be used, once you decide to do it. Right now just demanding a specific keyword in the subject line is more than enough to keep the spammers out. Later, I'm sure, cryptographic techniques will become necessary as spammers start parsing bounce messages and looking for clues. But right now this is all you need to do... it works, it works well, and it's easy to implement...
The primary accomplishment of these technologies is to make it difficult to scam e-mail recipiants.
You're mixing up phishing and similar identity theft scams and spamming. This is like arguing that laws against online porn will stop spam: you're targeting particular uses of spam... and this has never worked except partially and temporarily.
DomainKeys [...] also allows easy blacklisting of known spam servers.
We already know from the contents of the message, from the source address, the envelope, and the headers, exactly where the spam is injected. DomainKeys provides precisely NO new information about the source of spam.
ISP's will be more strict about letting spammers use their SMTP servers out of fear of being blacklisted.
Spammers don't use their ISPs servers, except by accident. They run an SMTP server right on the injecting system, and spam direct from the dialup, Cable, ADSL, or T1. When possible they don't even own the injecting system: it's a hijacked wireless link or a PC they've taken over with a virus. When they do find they're going through the ISP's servers they switch to a different ISP, because the only reason an ISP forces SMTP connections through their SMTP servers is to block spam.
Uh, yes, we already covered this. More resources applied to them, more benefit. Absolutely.
PowerPC has had lots of resources poured at it. IBM, Apple and Motorola have worked hard at it.
Well, IBM and Motorola have worked at it... Apple doesn't do chip design.
the hi-end CPU's (POWER, SPARC etc.) are fast
SPARC isn't much of a CPU. Again, it's a perfect example of the cost of architectural mistakes... in this case the Sparc register windows caused serious problems for Sun, and it's always been the most anemic of all the RISCs, the only one to never show any serious advantage over the x86.
x86-CPU's are doing just fine
Yeh, with an order of magnitude more cash spent on making them do fine. And how are they doing it? They built a recompiler into the hardware, and converted the x86 instructions into RISC instructions, and made those go fast! If they didn't have to effectively convert x86 instructions into Alpha instructions in hardware (hence, inefficiently) they'd be able to leave a huge chunk of silicon and a bunch of pipeline stages off.
what you are saying is that "if these other CPU's had infinite resources at their disposal, they would walk all over x86!"
I'm saying that if Intel was spending their money on an architecture that didn't suck, they would be building faster chips and they wouldn't be running into a performance wall right now. I'm saying that architecture matters, that the fact that Intel has been able to keep x86 in the race by heroic efforts doesn't mean that there's nothing wrong with the x86... it just means that the market matters as well.
I don't know about the weather forecast for hell, but you seem to have an unlimited ability to put words into my mouth, so no doubt you'll come back with yet another ludicrous rehash of something I didn't quite say. Please try and restrain yourself.
x86 (the architecture) is not holding those CPU's back. Hell, they have been getting faster and faster all the time.
The second sentence does not constitute support for the first sentence. ALL chip designs are getting faster as process technology improves, even the more-or-less abandoned Alpha has benefitted from that.
Or are you claiming that G5 or Itanium do not have enough resources behind them?... [G5] should walk all over P4/Athlon64/Opteron.
Itanium is a perfect example of why architecture matters, and I'll get back to that in a second.
The Power PC architecture is the low-end cousin to Power. Not only is it an older design than the Alpha, it's not strategic for either IBM or Motorola. You're right, it has not had nearly the same kind of resources thrown at it as the x86.
Itanium now... IA64 is an incredibly complex architecture that exposes a huge amount of internal state to the compiler. It isn't a RISC, really, and it was a tremendous gamble on Intel's part. On top of being almost a completely new approach to instruction set architecture it's got some questionable design features that have caused serious problems for other chips in the past.
I was extremely skeptical, even dismissive, of the design when it came out. The second generation does seem to have dealt with some of the problems and (more significantly) the compilers are finally beginning to get to the point where they can take advantage of it. I've been working on HPUX on Itanium 2 lately, and the latest compilers are mind-boggling. This is not necessarily a good thing, it makes debugging a lot more exciting than I really enjoy.
Since we're the only two people reading this any more, I'll just suggest you go back and re-read the message you're responding to and look at the bit where I pointed out how more complex stages can become a clock speed bottleneck, and how Intel's been able to push process technology and processor design to overcome the handicap of the lousy x86 architecture... so far.
All of the oh-so-ironic questions you're asking here are answered there, if you could be bothered to read what I actually wrote instead of being arch.
If you start with only usability in mind, and end up with a design that has inherent security flaws, it's easy to end up in a situation where the only way to improve security is to reduce usability. Internet Explorer is, of course, the poster boy fo rthis problem.
If you start with security in mind, and maintain both security and usability goals, you can end up with a much more secure design that, by the end of the day, is also more usable.
For example, if you build a rendering component that doesn't contain a mechanism for breaking out of its sandbox, and then let specific applications add capabilities that objects they directly provide to the rendering engine can use, you can implement almost every piece of functionality that Microsoft designed ActiveX for without having an ever-tightening ring of increasingly annoying restrictions wrapped about the user.
The only difference is that rather than having Internet Explorer at the core of the system, so that everything ends up looking like part of IE, you have a variety of applications with embedded HTML panes that provide the same functionality.
What do you lose? The ability to have remote web pages embed trusted control inside their web pages... instead you need to explicitly install plugins or, for in-house tools, run an "intranet update" that downloads and updates the apps.
This seems less convenient, until you realise the browser is more convenient in other ways because it's not trying to second-guess everything you do... and, once enough people are using it, the convenience of a more spam- and virus- free mailbox has to count for something.
You are still inferring things that I have not stated and that I do not believe I have implied. I do understand, on reviewing my original message, how you could have been confused... but surely by the time you read message 10801727 it should have been clear that this in not what I meant.
It is being done in user space, as a daemon, already.
At no time have I asserted that the majority of the work was NOT being done in user space as a daemon. The only issue was how the daemon was able to determine when to do that work.
It is not being done in HFS+ (beneath the vnode layer).
I have not at any time asserted that the entire operation is being done in any specific part of the system.
The meta data being discussed is not icon, label, or hfs fork metadata.
At no time have I asserted that it was. I merely pointed out that the way Apple described it was misleading if your statements were correct.
The meta data includes such things as [blah blah]
The daemon doesn't need to update that data in real time, it only needs to know if there's been a change it needs to look at.
Changes to file contents will generally require triggering an update to meta-data indexing.
Changes to file contents should already involve updating the last-modified-time of the file. Therefore unless I'm missing something you do not need to monitor file writes to know when a change to the file content has occurred, you only need to monitor changes to the last-modified-time in the vnode. In fact, you don't even need to do that much: any change to the vnode, including updating the timestamp, will put it on the dirty list, and a flush will move it back to the free list. Any modifications to the file contents will be bracketed between these two operations, and so that's all the daemon needs to be informed of.
Block writes would have to trigger a notification.
I don't believe so.
Instead, they wrote a daemon, which can check new and modified files,
Which means that the daemon either needs to traverse the file system (thanks for noticing, I already know that... that's the whole point of this exercise), or have a mechanism specific to the file system to find modified files, or have a mechanism operating above the file system layer to find modified files.
My original assumption was that it was using a file-system-specific mechanism. Thank you for confirming that it is in fact using a file-system-specific mechanism, and that I was in fact correct as to the reason it's only implemented for HFS+.
Well, that too. most CPUs have multiple parallel pipelines, but that's a completely different issue from the number of pipeline stages they have. Anyway, let's skip over most of the rant about my not getting it and cut to the chase:
Having less stages generally boosts the amount of work getting done per clock-cycle.
Actually, it doesn't. The amount of work you can do within a given clock cycle is pretty much limited by the process technology. You can tweak it a bit by running multiple operations in parallel (more pipelines and functional units), or by otherwise trading off chip real estate for shorter critical paths, but eventually there's some stage that can't be run any faster because there's not enough room within a clock cycle to complete that stage.
At the same time you still want as few stages as you can, because the more instructions you have in flight the bigger the penalty when you're blocked on some dependency.
But retiring an instruction, from the point it hits the decoder to the point all its results are committed, still represents a certain amount of work. If you have fewer stages, then the bottom line is that you have to complete a larger percent of that work within each stage. There's really only two ways of doing this, and that's to either run at a lower clock so each stage has more time to complete its part of the work, or decrease the amount of work you need to perform to retire the instruction.
And THAT is where the architecture comes in.
If your instruction set is designed so that it can be easily decoded, and if it's designed so that dependencies between operations are easy to extract (and if the compiler can tell you what they are, even better), then there's simply less work that needs to be done in the chip to retire the instruction.
And that is why the architecture matters, and why an architecture can force an implementation to use a longer pipeline. The architecture defines how much work needs to be done to retire an instruction and how much of that is overhead. The Alpha instruction set did a very good job of minimising that overhead. The x86 instruction set is not horrible from this viewpoint... it's better than most instruction sets that survived the late '70s and early '80s... but on today's hardware the overhead it imposes is great enough that it's cheaper to have the processor recompile it into a completely different instruction set than to try and make it run fast.
I don't care what the situation was in the 90's, I care what the situation is today.
The situation today is that huge amounts of resources are being expended on making an instruction set that's a very poor match for todays processor technology run very fast. Given comparable resources, the Alpha (or any other RISC instruction set designed to execute on modern hardware) would go much faster.
The situation today is a lesson in the effect of politics and marketing on processor performance. It tells you nothing about architecture, so it doesn't matter how many times you repeat "The architecture has nothing to do with the number of pipeline-stages" you won't make it any truer by pointing to what superior process and bigger bankrolls can do to overcome the x86 handicap.
And the situation in the '90s is important because it shows the effect that architecture has on performance. A lesson that may soon come to the forefront again, since process and implementation seem to be running out of headroom.
IIRC, in the later stages of it's life, Alpha-CPU's were having serious problems ramping up their clock-speed.
In the later stages of its life the Alpha was being systematically starved of resources by Compaq, for reasons that only became clear when the HP merger was announced. You certainly can't measure the architecture based on the Alpha speed and performance curve since the merger, or even for at least a year or two before it... the fact that it managed to stay competitive for as long as it did is bloody amazing.
Architecture (x86 etc.) has nothing to do with the number of pipeline-stages.
The architecture doesn't say "you must have N pipeline stages" no, and I was obviously being flip, but to claim that the architecture has nothing to do with he number of pipeline stages necessary to efficiently implement it implies either extreme naivete or an attempt to muddy the waters.
12-14 pipeline stages is still pretty high, when the next generation Alpha was only going to have nine, and when the Athlon is clock-limited by the complexity of its pipeline stages while Alpha had been able to stay ahead in both clock and performance throughout the '90s... with only seven.
I always thought that what killed A/UX off was that it wouldn't run on the powerpc
I think it would have to be the other way around. A/UX wasn't ported to the Power PC because it was already dead. Porting a UNIX implementation to another processor, by the mid '90s, was practically an undergrad term project. Porting the emulation environment for the GUI would have been a bit more work, but they were doing that part anyway.
What killed A/UX was that performance sucked, and there wasn't enough demand for a server-only OS.
I thought they wanted to solve the problems of memory protection, a TCP/IP stack, and multiple users
Before 1985, when the fight was going on? Hardly. There was no TCP on any home computer, and no home computer OS even had hooks for memory protection or multiple users... but the Amiga did. They dropped the ball on them later on by not enforcing MEMF_PUBLIC (which was supposed to be used if and ONLY if you were allocating shared memory), but there was thought put into it in the original design.
Hey, Krank, let's say you've got two otherwise identical computer cases you're looking at. One's $45 and the other's $55... but it's got a "tux" theme and comes with a Debian CD autographed by Linus.
There's no big difference between Linux/BSD and Windows NT/2K/XP in security, architecturally.
Windows NT: Large complex API with security boundary crossings scattered throughout, mediated by the callee.
UNIX: Small simple API with security boundary crossings all at the system call interface, mediated by a uniform calling mechanism with basic boundary and argument validity checks performed in one place.
Windows NT: Finely grained rights system associated with the logged in user. A user must have all rights required for any operation all the time.
UNIX: Simple rights system associated with the user, or the application. Applications may be configured to automaticaly run with a different efective user ID, temporarily, to avoid having to grant a user all possible rights they may need.
Windows: Loose boundaries between applications and other components, libraries frequently have considerable state that can be shared between applications, even under different user IDs.
UNIX: Tight boundaries between applications, simple shared libraries that rarely maintain state out of sight of the application.
There are advantages to the Windows model. A lot of operations can be performed much more efficiently if there's no strong security boundary between components. The tradeoff is that applications come to depend on low overhead high performance communications channels.
A few years back, before Microsoft bought into Citrix technology, there was another Windows virtualization product called NTerprise. Under NTerprise, GDI calls were translated into X11 calls, with appropriate message bundling to provide decent performance. It was a lot more responsive than Citrix, and for most apps it was at least as fast over a local LAN. A few apps, however, performed very badly. Microsoft Project, for example, seemed to require a round-trip to the display for every cell, and repainted the entire page for just about any change... so you'd add a new deadline, and then sit back as the whole workspace was repainted, slowly, three times.
An insecure shell environment does not make the entire operating system insecure.
Technically, in a really literal minded sense, that's correct. Technically, any Win32 component or control can be replaced. In practice, the way that Microsoft has built the system too much depends on the HTML control and Windows Explorer. For the former, many control panel objects use the HTML control for rendering, and depend on the ability of the HTML control to run trusted objects that have full local user access. For the latter, instead of mounting devices like my Jornada in the file system, they're shown on the desktop but are only there via a plugin for Windows Explorer, so without it I can't browse my Pocket PC.
So, in practice, they're ubiquitous and unavoidable. While I was able to get good results at work by banning Outlook and Internet Explorer (which I did before Melissa hit... I had no idea what the results of the Active Desktop fiasco would be, and I was stunned when Microsoft refused to change the design after Melissa should have made it obvious that they were going down the wrong track), over time more and more software has come to depend on these interactions.
Win32 does, however, have desktop, window station and job objects that are designed to be used to divide Win32 into seperate little pieces, each unable to talk to one another.
I can't have a great deal of faith in that design. There's just too much shared state between components of Windows, and too little control over the implementation of security boundaries: every component seems to have its own call gates, with multiple independent implementations of the same security and sanity checks on arguments and objects.
All it takes is one missed check, in one call, and you're out of the box.
Slashdot Mirror
Sun One, formerly iPlanet? We made that mistake, too. We'd used Netscape's Apache port previously, when we had customers who wanted a commercial webserver for some odd reason, so when that went to iPlanet, we followed. Oh my god, was that painful.
Reminded me of what happened to SCO UNIX. Xenix, in the '80s, was actually a pretty solid small-office OS. Then they started adding stuff to it, redid it using System V and kept everything they already had. So now you had two sets of drivers and configuration. Repeat a few more times with SCO UNIX and SCO Openserver and SCO UNIXware, and pretty soon you needed the curses then X11 config tools because the stuff underneath was so damn complex there was no way to figure out WTF went where.
Windows is like that, too, but nobody but Microsoft is expected to know how far the turtles go down so people put up with it.
Oracle, oh my god, NINE GIGABYTES for a DBMS?
Solaris actually seems pretty good in comparison.
WTF does the phrase "a desktop-only version of Linux" mean?
I remember seeing pictures of this chess set doing the rounds years ago. Nice to get an update.
Clarifying one point: When the daemon is started, it does a pass over any files on the watch list and updates their info.
I don't mean that it only checks files on the watch list when it starts, I mean that when it starts it does an extra exhaustive pass over the watch-list to catch any files that may have been open when it was previously terminated. In normal use it would check when the file was closed or when it had been open longer than whatever the daemon's update window was.
I assumed you were misinformed about those issue because of your continued insistence that the technology is file system specific, and that kernel notifications offer potential improvement.
you appeared to be claiming that it will only work at all on hfs volumes
Crikey. Go back and read what I actually wrote. Can you see where I already referred to software (glimpse, harvest) that does a similar thing using exhaustive traversal of the file system? So claiming that I've said that you can't do the same thing without a hook like this (either the one Apple's using, or a notification scheme) seems pretty damned weird to me. What I said was that you couldn't do it efficiently:
it is not file system specific in the first place
Since the overhead of exhaustive traversal is simply prohibitive, unless you're going to be satisfied by a database that's hours or days out of date. Being hours out of date is fine for something like Google, but for Spotlight it's a killer. You need a better mechanism to keep it both fast and efficient enough for this application, and the one Spotlight is using is file-system specific.
(I've actually tried variations on this using both Harvest and my own software, and the amount of filesystem activity you need to stay within a shorter window, on any reasonably sized filesystem, is horrible)
You assert that notifications need only be sent when mtime changes, not for each file system write. This does not make sense.
Actually, THAT part makes sense. Apparently the mechanism I assumed I could use for efficiently detecting that isn't there, but that doesn't mean that the only alternative is to put a kqueue call in the critical path of block writes.
Here's another mechanism that would work:
Track the VOPs that I already listed, plus OPEN and CLOSE. When the daemon sees an OPEN for write or modify, that file goes on a watch list. When the daemon sees a close, the file goes off the list. When the daemon is started, it does a pass over any files on the watch list and updates their info.
This isn't as good as getting mtime notifications, because it's got to dynamically monitor files it could have passively monitored before. But next to an exhaustive traversal it's incomparably better.
What will they do when stick-on wireless webcams and scriptable flashcams cost about the same as those cheap digital watches they give away as prizes in happy meals?
THIS WAR IS LOST, you better welcome the transparent society or prepare for a police state.
But with 99% global cooperation, wouldnt this solution provide additional accuracy for existing spam filters?
With 99% global cooperation we could stop spam in a year any number of ways that would be easier and less damaging than adding layers of criplling checks to every SMTP transaction.
The reason we need technological aids to fight spam is simply because we can't get anything like that. It took years of hard work and real effective blacklisting by RBLs just to get as much cooperation as we currently have. Getting 99% of ISPs or even getting the ISPs responsible for 99% of the global market to agree on things as simple as blocking port 25 for dial-up users... let alone cooperating in something like this... is science fiction.
This is precisely the form of spam that will be impossible under domain keys.
Only if DomainKeys are universally supported for all such cases. And ISPs are willing to let their own customers register when it's appropriate.
I mean, we can already block dynamic addresses through an RBL pretty reliably, and since you're assuming enough ISPs go along to make it worthwhile you might as well assume they would self-RBL their own dynamic space and make it absolutely accurate.
And they haven't, in general.
This may help, though I'm not at all convinced that it'll be as effective as an RBL and they don't even make an order of magnitude difference in the spam level. To really have an impact on spammers, you need at least three nines coverage and you need to keep the spammers from working around it, or they'll just concentrate in the part of the net that's not served by cooperative ISPs... and that's an awful lot of it.
I surely hope you are right.
Crossing my fingers, crossing my toes...
It sure as hell won't run on my SS1+ and SS2!
Solaris became "bloatware" with the first release labelled Solaris. SunOS 4 uber alles!
Linux is effectively under a license more like the LGPL, since Linus allows companies to distribute drivers without GPLing them. So it seems, at least, to share the attributes of the LGPL that would make it compatible with almost all FOSS licenses so long as components under other licenses are distributed as loadable modules.
whats really needed is a CPU intensive solution like the hashcash suggestion
Which kills legitimate mailing lists.
There's one way to prevent spam and that's to make it a lot more expensive in human time to send unsolicited bulk email. There's no way to do this, though, without making it a little more expensive in human time to send single messages, or to sign up to a mailing list.
I've been using it for my family's mail for the past few years and so far as I know a total of one Nigerian has decided it's worth their time to jump through the hoop to get in.
The problem with this is that people who haven't yet accepted that spam can't be solved without making mail a little harder to use aren't willing to jump through any hoops, and that most people running mailing lists aren't yet set up to give people the necessary information to whitelist them.
There's a bunch of different mechanisms that can be used, once you decide to do it. Right now just demanding a specific keyword in the subject line is more than enough to keep the spammers out. Later, I'm sure, cryptographic techniques will become necessary as spammers start parsing bounce messages and looking for clues. But right now this is all you need to do... it works, it works well, and it's easy to implement...
The primary accomplishment of these technologies is to make it difficult to scam e-mail recipiants.
You're mixing up phishing and similar identity theft scams and spamming. This is like arguing that laws against online porn will stop spam: you're targeting particular uses of spam... and this has never worked except partially and temporarily.
DomainKeys [...] also allows easy blacklisting of known spam servers.
We already know from the contents of the message, from the source address, the envelope, and the headers, exactly where the spam is injected. DomainKeys provides precisely NO new information about the source of spam.
ISP's will be more strict about letting spammers use their SMTP servers out of fear of being blacklisted.
Spammers don't use their ISPs servers, except by accident. They run an SMTP server right on the injecting system, and spam direct from the dialup, Cable, ADSL, or T1. When possible they don't even own the injecting system: it's a hijacked wireless link or a PC they've taken over with a virus. When they do find they're going through the ISP's servers they switch to a different ISP, because the only reason an ISP forces SMTP connections through their SMTP servers is to block spam.
x86-CPUs just benefitted even more.
Uh, yes, we already covered this. More resources applied to them, more benefit. Absolutely.
PowerPC has had lots of resources poured at it. IBM, Apple and Motorola have worked hard at it.
Well, IBM and Motorola have worked at it... Apple doesn't do chip design.
the hi-end CPU's (POWER, SPARC etc.) are fast
SPARC isn't much of a CPU. Again, it's a perfect example of the cost of architectural mistakes... in this case the Sparc register windows caused serious problems for Sun, and it's always been the most anemic of all the RISCs, the only one to never show any serious advantage over the x86.
x86-CPU's are doing just fine
Yeh, with an order of magnitude more cash spent on making them do fine. And how are they doing it? They built a recompiler into the hardware, and converted the x86 instructions into RISC instructions, and made those go fast! If they didn't have to effectively convert x86 instructions into Alpha instructions in hardware (hence, inefficiently) they'd be able to leave a huge chunk of silicon and a bunch of pipeline stages off.
what you are saying is that "if these other CPU's had infinite resources at their disposal, they would walk all over x86!"
I'm saying that if Intel was spending their money on an architecture that didn't suck, they would be building faster chips and they wouldn't be running into a performance wall right now. I'm saying that architecture matters, that the fact that Intel has been able to keep x86 in the race by heroic efforts doesn't mean that there's nothing wrong with the x86... it just means that the market matters as well.
I don't know about the weather forecast for hell, but you seem to have an unlimited ability to put words into my mouth, so no doubt you'll come back with yet another ludicrous rehash of something I didn't quite say. Please try and restrain yourself.
x86 (the architecture) is not holding those CPU's back. Hell, they have been getting faster and faster all the time.
... [G5] should walk all over P4/Athlon64/Opteron.
The second sentence does not constitute support for the first sentence. ALL chip designs are getting faster as process technology improves, even the more-or-less abandoned Alpha has benefitted from that.
Or are you claiming that G5 or Itanium do not have enough resources behind them?
Itanium is a perfect example of why architecture matters, and I'll get back to that in a second.
The Power PC architecture is the low-end cousin to Power. Not only is it an older design than the Alpha, it's not strategic for either IBM or Motorola. You're right, it has not had nearly the same kind of resources thrown at it as the x86.
Itanium now... IA64 is an incredibly complex architecture that exposes a huge amount of internal state to the compiler. It isn't a RISC, really, and it was a tremendous gamble on Intel's part. On top of being almost a completely new approach to instruction set architecture it's got some questionable design features that have caused serious problems for other chips in the past.
I was extremely skeptical, even dismissive, of the design when it came out. The second generation does seem to have dealt with some of the problems and (more significantly) the compilers are finally beginning to get to the point where they can take advantage of it. I've been working on HPUX on Itanium 2 lately, and the latest compilers are mind-boggling. This is not necessarily a good thing, it makes debugging a lot more exciting than I really enjoy.
Since we're the only two people reading this any more, I'll just suggest you go back and re-read the message you're responding to and look at the bit where I pointed out how more complex stages can become a clock speed bottleneck, and how Intel's been able to push process technology and processor design to overcome the handicap of the lousy x86 architecture... so far.
All of the oh-so-ironic questions you're asking here are answered there, if you could be bothered to read what I actually wrote instead of being arch.
If you start with only usability in mind, and end up with a design that has inherent security flaws, it's easy to end up in a situation where the only way to improve security is to reduce usability. Internet Explorer is, of course, the poster boy fo rthis problem.
If you start with security in mind, and maintain both security and usability goals, you can end up with a much more secure design that, by the end of the day, is also more usable.
For example, if you build a rendering component that doesn't contain a mechanism for breaking out of its sandbox, and then let specific applications add capabilities that objects they directly provide to the rendering engine can use, you can implement almost every piece of functionality that Microsoft designed ActiveX for without having an ever-tightening ring of increasingly annoying restrictions wrapped about the user.
The only difference is that rather than having Internet Explorer at the core of the system, so that everything ends up looking like part of IE, you have a variety of applications with embedded HTML panes that provide the same functionality.
What do you lose? The ability to have remote web pages embed trusted control inside their web pages... instead you need to explicitly install plugins or, for in-house tools, run an "intranet update" that downloads and updates the apps.
This seems less convenient, until you realise the browser is more convenient in other ways because it's not trying to second-guess everything you do... and, once enough people are using it, the convenience of a more spam- and virus- free mailbox has to count for something.
You are still inferring things that I have not stated and that I do not believe I have implied. I do understand, on reviewing my original message, how you could have been confused... but surely by the time you read message 10801727 it should have been clear that this in not what I meant.
It is being done in user space, as a daemon, already.
At no time have I asserted that the majority of the work was NOT being done in user space as a daemon. The only issue was how the daemon was able to determine when to do that work.
It is not being done in HFS+ (beneath the vnode layer).
I have not at any time asserted that the entire operation is being done in any specific part of the system.
The meta data being discussed is not icon, label, or hfs fork metadata.
At no time have I asserted that it was. I merely pointed out that the way Apple described it was misleading if your statements were correct.
The meta data includes such things as [blah blah]
The daemon doesn't need to update that data in real time, it only needs to know if there's been a change it needs to look at.
Changes to file contents will generally require triggering an update to meta-data indexing.
Changes to file contents should already involve updating the last-modified-time of the file. Therefore unless I'm missing something you do not need to monitor file writes to know when a change to the file content has occurred, you only need to monitor changes to the last-modified-time in the vnode. In fact, you don't even need to do that much: any change to the vnode, including updating the timestamp, will put it on the dirty list, and a flush will move it back to the free list. Any modifications to the file contents will be bracketed between these two operations, and so that's all the daemon needs to be informed of.
Block writes would have to trigger a notification.
I don't believe so.
Instead, they wrote a daemon, which can check new and modified files,
Which means that the daemon either needs to traverse the file system (thanks for noticing, I already know that... that's the whole point of this exercise), or have a mechanism specific to the file system to find modified files, or have a mechanism operating above the file system layer to find modified files.
My original assumption was that it was using a file-system-specific mechanism. Thank you for confirming that it is in fact using a file-system-specific mechanism, and that I was in fact correct as to the reason it's only implemented for HFS+.
The CPU can have any number of pipelines.
Well, that too. most CPUs have multiple parallel pipelines, but that's a completely different issue from the number of pipeline stages they have. Anyway, let's skip over most of the rant about my not getting it and cut to the chase:
Having less stages generally boosts the amount of work getting done per clock-cycle.
Actually, it doesn't. The amount of work you can do within a given clock cycle is pretty much limited by the process technology. You can tweak it a bit by running multiple operations in parallel (more pipelines and functional units), or by otherwise trading off chip real estate for shorter critical paths, but eventually there's some stage that can't be run any faster because there's not enough room within a clock cycle to complete that stage.
At the same time you still want as few stages as you can, because the more instructions you have in flight the bigger the penalty when you're blocked on some dependency.
But retiring an instruction, from the point it hits the decoder to the point all its results are committed, still represents a certain amount of work. If you have fewer stages, then the bottom line is that you have to complete a larger percent of that work within each stage. There's really only two ways of doing this, and that's to either run at a lower clock so each stage has more time to complete its part of the work, or decrease the amount of work you need to perform to retire the instruction.
And THAT is where the architecture comes in.
If your instruction set is designed so that it can be easily decoded, and if it's designed so that dependencies between operations are easy to extract (and if the compiler can tell you what they are, even better), then there's simply less work that needs to be done in the chip to retire the instruction.
And that is why the architecture matters, and why an architecture can force an implementation to use a longer pipeline. The architecture defines how much work needs to be done to retire an instruction and how much of that is overhead. The Alpha instruction set did a very good job of minimising that overhead. The x86 instruction set is not horrible from this viewpoint... it's better than most instruction sets that survived the late '70s and early '80s... but on today's hardware the overhead it imposes is great enough that it's cheaper to have the processor recompile it into a completely different instruction set than to try and make it run fast.
I don't care what the situation was in the 90's, I care what the situation is today.
The situation today is that huge amounts of resources are being expended on making an instruction set that's a very poor match for todays processor technology run very fast. Given comparable resources, the Alpha (or any other RISC instruction set designed to execute on modern hardware) would go much faster.
The situation today is a lesson in the effect of politics and marketing on processor performance. It tells you nothing about architecture, so it doesn't matter how many times you repeat "The architecture has nothing to do with the number of pipeline-stages" you won't make it any truer by pointing to what superior process and bigger bankrolls can do to overcome the x86 handicap.
And the situation in the '90s is important because it shows the effect that architecture has on performance. A lesson that may soon come to the forefront again, since process and implementation seem to be running out of headroom.
IIRC, in the later stages of it's life, Alpha-CPU's were having serious problems ramping up their clock-speed.
In the later stages of its life the Alpha was being systematically starved of resources by Compaq, for reasons that only became clear when the HP merger was announced. You certainly can't measure the architecture based on the Alpha speed and performance curve since the merger, or even for at least a year or two before it... the fact that it managed to stay competitive for as long as it did is bloody amazing.
Architecture (x86 etc.) has nothing to do with the number of pipeline-stages.
The architecture doesn't say "you must have N pipeline stages" no, and I was obviously being flip, but to claim that the architecture has nothing to do with he number of pipeline stages necessary to efficiently implement it implies either extreme naivete or an attempt to muddy the waters.
12-14 pipeline stages is still pretty high, when the next generation Alpha was only going to have nine, and when the Athlon is clock-limited by the complexity of its pipeline stages while Alpha had been able to stay ahead in both clock and performance throughout the '90s... with only seven.
I always thought that what killed A/UX off was that it wouldn't run on the powerpc
I think it would have to be the other way around. A/UX wasn't ported to the Power PC because it was already dead. Porting a UNIX implementation to another processor, by the mid '90s, was practically an undergrad term project. Porting the emulation environment for the GUI would have been a bit more work, but they were doing that part anyway.
What killed A/UX was that performance sucked, and there wasn't enough demand for a server-only OS.
I thought they wanted to solve the problems of memory protection, a TCP/IP stack, and multiple users
Before 1985, when the fight was going on? Hardly. There was no TCP on any home computer, and no home computer OS even had hooks for memory protection or multiple users... but the Amiga did. They dropped the ball on them later on by not enforcing MEMF_PUBLIC (which was supposed to be used if and ONLY if you were allocating shared memory), but there was thought put into it in the original design.
Hey, Krank, let's say you've got two otherwise identical computer cases you're looking at. One's $45 and the other's $55... but it's got a "tux" theme and comes with a Debian CD autographed by Linus.
There's no big difference between Linux/BSD and Windows NT/2K/XP in security, architecturally.
Windows NT: Large complex API with security boundary crossings scattered throughout, mediated by the callee.
UNIX: Small simple API with security boundary crossings all at the system call interface, mediated by a uniform calling mechanism with basic boundary and argument validity checks performed in one place.
Windows NT: Finely grained rights system associated with the logged in user. A user must have all rights required for any operation all the time.
UNIX: Simple rights system associated with the user, or the application. Applications may be configured to automaticaly run with a different efective user ID, temporarily, to avoid having to grant a user all possible rights they may need.
Windows: Loose boundaries between applications and other components, libraries frequently have considerable state that can be shared between applications, even under different user IDs.
UNIX: Tight boundaries between applications, simple shared libraries that rarely maintain state out of sight of the application.
There are advantages to the Windows model. A lot of operations can be performed much more efficiently if there's no strong security boundary between components. The tradeoff is that applications come to depend on low overhead high performance communications channels.
A few years back, before Microsoft bought into Citrix technology, there was another Windows virtualization product called NTerprise. Under NTerprise, GDI calls were translated into X11 calls, with appropriate message bundling to provide decent performance. It was a lot more responsive than Citrix, and for most apps it was at least as fast over a local LAN. A few apps, however, performed very badly. Microsoft Project, for example, seemed to require a round-trip to the display for every cell, and repainted the entire page for just about any change... so you'd add a new deadline, and then sit back as the whole workspace was repainted, slowly, three times.
An insecure shell environment does not make the entire operating system insecure.
Technically, in a really literal minded sense, that's correct. Technically, any Win32 component or control can be replaced. In practice, the way that Microsoft has built the system too much depends on the HTML control and Windows Explorer. For the former, many control panel objects use the HTML control for rendering, and depend on the ability of the HTML control to run trusted objects that have full local user access. For the latter, instead of mounting devices like my Jornada in the file system, they're shown on the desktop but are only there via a plugin for Windows Explorer, so without it I can't browse my Pocket PC.
So, in practice, they're ubiquitous and unavoidable. While I was able to get good results at work by banning Outlook and Internet Explorer (which I did before Melissa hit... I had no idea what the results of the Active Desktop fiasco would be, and I was stunned when Microsoft refused to change the design after Melissa should have made it obvious that they were going down the wrong track), over time more and more software has come to depend on these interactions.
Win32 does, however, have desktop, window station and job objects that are designed to be used to divide Win32 into seperate little pieces, each unable to talk to one another.
I can't have a great deal of faith in that design. There's just too much shared state between components of Windows, and too little control over the implementation of security boundaries: every component seems to have its own call gates, with multiple independent implementations of the same security and sanity checks on arguments and objects.
All it takes is one missed check, in one call, and you're out of the box.