I've still been too cheap to buy one, though. I've just re-soldered mine every time it breaks. (Four times and counting. My wife and kids can't seem to get the idea that stress at odd angles wears the wire out.)
Yeah, the puck was a bad design.
Yeah, if you need a PS without the electrical tape, get a 3rd party unit.
Oh, and the apple tech note someone posted a link to explains a bit about that little blue part that seemed to just go from ground to ground. The shell isn't really ground, but the connection for the resistor that the internal circuitry can use to check the type of the power brick.
Particularly because the 386, being supposedly equivalent to the 68020 or 68030 or 68040 or something, was thought by a lot of PHBs to be sufficient, not realizing that the OS would either get in the way or fail to support the project at a critical time (requiring preparation to get around).
Which is all part of the reason Linus's little project exploded.
Microprocessor CPUs were finally getting "good enough", and Linus provided the kernel and GNU provided the tools.
(68Ks without MMUs were not really good enough, either, and even the current crop are just barely good enough, only partially covering the deficiencies with speed. W^X and the like are bringing us closer. The next step is, not surprisingly, to separate the call/return stack and its address space from the paramater stack and its address space, and there are about two more separations that have to occur before anyone can really trust a CPU to execute only the program fed and nothing else -- which really is not what TPM is all about, either. I'm rambling.)
Hey, I fought with the segment registers, too. I hate them. I still refuse to buy iNTEL processors because of the scars.
But I personally watched a number of projects on 68K go down the tubes as management and engineering kept adding features to apps before they were running at all, just because the 68K, being the better processor, should have been able to support the extra features. Disciplined engineers would not fall into such traps, but since when has management been disciplined? Since when has ascetism been a popular goal with marketing?
Just adding a stack is no good. You have to be coordinated about it.
I mentioned, I think, dedicated stack caches? Hysteric, with spill and fill at the 1/4 and 3/4 points? Much less complicated than 4-way set associative, and much smaller for the performance gain. And that cache is what the renaming function maps onto.
Cache for the call/return stack only needs to be maybe 16 or 32 words deep for almost any GP hardware, including all consumer stuff.
Cache for the parameter stack would need a bit more, but 1K words would be easily sufficient for moste purposes. Needless to say, renaming would only target the top 16 or 32 registers.
Small stack cache would allow implementing cache pairs for faster context switching. (Sets of four might be useful for dedicated real-time hardware.)
There are other optimization that are enabled (but not implied) by using multiple stacks. But it's my bedtime now, so I'll leave it alone.
32 bits of address and a decent architecture let all sorts of products get blown out of proportion in the design phase on the 68K.
Those 64K segments forced product managers to remain focused. I mean, it gave them an excuse to tell both margeting and their engineers to put that wonderful new feature on the back burner until time to start the next version.
are mostly derived from everyone being dazzled by the magic and missing the meaning.
The biggest issue is the source of the compactness. That much code re-use makes it difficult to separate modules, either for design purposes or for security/safety.
I'd go on, but I have to go to bed. Graveyard shift was fun, but I'm tired.
I'll tire of saying so pretty soon, but here is one more try.
The current x86 chips _rename_ their registers to ease the bottleneck.
With only one TOS, renaming becomes a much simpler process. SWAP and ROT and DROP could easily become zero-cycle no-ops.
The pipline optimizer simply has to go hunting for independent leaf expressions, and since they are bounded by the patterns of growth and shrinkage of the stack, they should be easy to find. It has been done, and it works.
Direct threading actually turned out to be slower than indirect threading. I know from the implementation I did (which is still out there and downloadable, somewhere).
If a CISC with a small logical register set can find leafs in the pipe and distribute them to cores, even a true TOS limited stack processor could be designed to find the independent leaves and distribute them.
Sorry for the delayed reaction, but we used to have a saying, that the best sysad was usually the first true black hat in.
There are at least two games in play here, and it sounds like you're pretty good at shutting down the rape-and-pillage crowd.
These days, many of the moderately skilled crackers are more interested in not letting people know they are there, so they tend to just hide their own private back doors instead of risking exposure by tightening boxes down, especially MSWindows boxes that come cheap anyway. A skilled cracker is also likely to examine the potential host and only drop a private back door on a box that looks especially valuable for some reason.
You're taking a gamble, when you just clean the box, that the box in question is not "interesting" in the quieter game.
I think, if I were you, I'd at least make rich kids and people who have repeats pay for a re-install, installation of a router with a firewall if they don't have one, and setting up and training them to use a non-admin user account.
I'd be pushing them to get off MSWindows, too.
It's a game of odds, but I'd be trying to get my customers to play the better odds.
Come to think of it, a bigger question than whether they can make an exploit for PPC Macs (assuming the firmware is fat or something, I suppose), is whether they expect to be able to build an exploit that will work on openbsd.
I think that's what the specs are on the new silicon.
Anyway, Motorola's group has demonstrated non-interference at quite high bandwidth useage. Sure, there's a limit there somewhere, but there's a lot more headroom.
If a company's tech support should be berated for buying gen 1 macs, should Apple be berated for failing to continue to sell non-gen-1 macs during the transition?
Or, indeed, for not simply introducing the iNTEL lines and keeping the PPC lines going.
Yes, the market would have supported that.
One problem, of course, is that Apple would have had to keep the lines up to date in the year before the "switch". No complaints about fake unavailability.
Most of the problems with electronic voting machines are getting better attention this time around, but I still don't see much attention given to the problem that, for me, kills the whole idea of electronic voting, paper trail or otherwise.
We know that a well aimed antenna of appropriate characteristics can steal the data being typed at the typical keyboard.
What is to prevent the engineer who designs the motherboard from adding an innocuous physical loop in a data line somewhere and a carefully obscured bit of code that pumps every vote out that loop?
Then you have a few teenage geeks on the local political machine's payroll skateboarding and listening on AM radios outside the polling place, and one of those little cameras you can buy for about $35 these days focused on the voting booths, and the boss sends somebody around to offer a little education to those who voted wrong in the last election.
With a little social engineering, most of the recievers of the education will not even be aware that their vote was know, only that some influential friend is offering them political opinion that sounds kind of persuasive. And you don't have to educate the whole group, just those who seem respected in general.
I'm in favor of electronic tabulation, as long as the tabulation system doesn't force a design decision that makes it hard for the voter to check his or her vote. But the tabulation must be done after the ballot has been sequence-washed in the locked ballot box. And there should be a required hand tabulation, at the polling place, after the polls close, and before the election judges go home.
And no receipts, of course, no external paper trail that could be walked backwards in sequence in some dustly closet somewhere.
(Part of me sometimes wants to use random sequence numbers to make sure that the ballots in the box are the ones the judges had to pass out to the voters, but I have never been able to break the problem of walking the sequence backwards.)
Buy them a new HD for the Linux, swap the HDs so you have the original safe-and-sound, and install, what, RH? SuSE? Ubuntu or Knoppix?
Show them where all the software they will use instead of the Microsilt is and show them how to do what they want to do. (Firefox, one of a couple of options on e-mail, openoffice?)
Hang the original HD off as a slave and set it up so they can mount it read-only and get at their old data. Or maybe copy the old data to a special/olddata partition so the old drive can be saved as backup.
Make a date once or twice a week to come show them how to do what they can't figure out. You need the excuse to visit anyway, and you'll find after the second week that you actually do visit more than do geekly things.
Yeah, I admit, it was funky, although logical in a kind of twisty way, when Apple chose that paradigm.
What metaphor should they have chosen?
A picture of a cowboy getting off his horse? (un-mount. Get it?)
uhm, uhm, uhm, a picture of a mainframe tech pulling a tape off a tape drive?
(And how does one tell an icon representing mount from umount?)
A picture of a folder falling off the desk? Or the folder being moved from the desk to a filing cabinet? Well, how about the cabinet itself being wheeled into the safe? Or, maybe, wheeled out the front door?
The only decent idea I could come up with back then was having a duplicate trash folder on the desktop, with the icon changed to an open door or window.
Something to represent off-line?
Well, trash is off-line.
An open door or window also might invoke off-line.
Now that the descendents of boom-boxes are common small appliances even in less developed countries (yeah, less than what, and in what ways), the eject button ideograph makes a good descriptive image, too.
There were some (3rd party) system extensions that allowed one to change the icon on the fly -- when you started to drag the icon of a removable volume on the desktop, the trash icon changed to an icon of the user's choice. Common choices for the alternative icons were open windows and doors, and also that eject button image.
(I didn't like extensions multiplying like rabbits, and I didn't mind the trash metaphor, so I never even bothered keeping the duplicate trash with a different icon.)
So, now, in Mac OS X, when you start to drag the icon of a volume on the desktop, the trash icon changes to that eject-button ideograph. Where's the beef?
(I did note that dragging a volume icon from that panel on the left of the metal Finder window does not change the trash icon. I could presume that preparing the puff-of-smoke swallows the event?)
Or, at least, you could the last time I checked.
I've still been too cheap to buy one, though. I've just re-soldered mine every time it breaks. (Four times and counting. My wife and kids can't seem to get the idea that stress at odd angles wears the wire out.)
Yeah, the puck was a bad design.
Yeah, if you need a PS without the electrical tape, get a 3rd party unit.
Oh, and the apple tech note someone posted a link to explains a bit about that little blue part that seemed to just go from ground to ground. The shell isn't really ground, but the connection for the resistor that the internal circuitry can use to check the type of the power brick.
Yeah, that happened, too.
Particularly because the 386, being supposedly equivalent to the 68020 or 68030 or 68040 or something, was thought by a lot of PHBs to be sufficient, not realizing that the OS would either get in the way or fail to support the project at a critical time (requiring preparation to get around).
Which is all part of the reason Linus's little project exploded.
Microprocessor CPUs were finally getting "good enough", and Linus provided the kernel and GNU provided the tools.
(68Ks without MMUs were not really good enough, either, and even the current crop are just barely good enough, only partially covering the deficiencies with speed. W^X and the like are bringing us closer. The next step is, not surprisingly, to separate the call/return stack and its address space from the paramater stack and its address space, and there are about two more separations that have to occur before anyone can really trust a CPU to execute only the program fed and nothing else -- which really is not what TPM is all about, either. I'm rambling.)
Hey, I fought with the segment registers, too. I hate them. I still refuse to buy iNTEL processors because of the scars.
But I personally watched a number of projects on 68K go down the tubes as management and engineering kept adding features to apps before they were running at all, just because the 68K, being the better processor, should have been able to support the extra features. Disciplined engineers would not fall into such traps, but since when has management been disciplined? Since when has ascetism been a popular goal with marketing?
Just adding a stack is no good. You have to be coordinated about it.
I mentioned, I think, dedicated stack caches? Hysteric, with spill and fill at the 1/4 and 3/4 points? Much less complicated than 4-way set associative, and much smaller for the performance gain. And that cache is what the renaming function maps onto.
Cache for the call/return stack only needs to be maybe 16 or 32 words deep for almost any GP hardware, including all consumer stuff.
Cache for the parameter stack would need a bit more, but 1K words would be easily sufficient for moste purposes. Needless to say, renaming would only target the top 16 or 32 registers.
Small stack cache would allow implementing cache pairs for faster context switching. (Sets of four might be useful for dedicated real-time hardware.)
There are other optimization that are enabled (but not implied) by using multiple stacks. But it's my bedtime now, so I'll leave it alone.
They actually kept a lot of important projects from getting overspecified in the first version.
Sometimes bad is good.
32 bits of address and a decent architecture let all sorts of products get blown out of proportion in the design phase on the 68K.
Those 64K segments forced product managers to remain focused. I mean, it gave them an excuse to tell both margeting and their engineers to put that wonderful new feature on the back burner until time to start the next version.
Jobs was only mildly interested in the performance roadmap. The fuss about it is a smokescreen.
are mostly derived from everyone being dazzled by the magic and missing the meaning.
The biggest issue is the source of the compactness. That much code re-use makes it difficult to separate modules, either for design purposes or for security/safety.
I'd go on, but I have to go to bed. Graveyard shift was fun, but I'm tired.
is way, way, overkill for the stack.
Expression leafs exist, the patterns of stack usage reveal them, if the leafs can be found they can be distributed.
No, the pipelines you're probably used to are not appropriate for the redistribution.
I'll tire of saying so pretty soon, but here is one more try.
The current x86 chips _rename_ their registers to ease the bottleneck.
With only one TOS, renaming becomes a much simpler process. SWAP and ROT and DROP could easily become zero-cycle no-ops.
The pipline optimizer simply has to go hunting for independent leaf expressions, and since they are bounded by the patterns of growth and shrinkage of the stack, they should be easy to find. It has been done, and it works.
by the virtual execution model. (Witness the 8086 descendent that is probably munching your data stream right now.)
loop:
jmp
bra loop
or something like that?
Direct threading actually turned out to be slower than indirect threading. I know from the implementation I did (which is still out there and downloadable, somewhere).
If a CISC with a small logical register set can find leafs in the pipe and distribute them to cores, even a true TOS limited stack processor could be designed to find the independent leaves and distribute them.
Sorry for the delayed reaction, but we used to have a saying, that the best sysad was usually the first true black hat in.
There are at least two games in play here, and it sounds like you're pretty good at shutting down the rape-and-pillage crowd.
These days, many of the moderately skilled crackers are more interested in not letting people know they are there, so they tend to just hide their own private back doors instead of risking exposure by tightening boxes down, especially MSWindows boxes that come cheap anyway. A skilled cracker is also likely to examine the potential host and only drop a private back door on a box that looks especially valuable for some reason.
You're taking a gamble, when you just clean the box, that the box in question is not "interesting" in the quieter game.
I think, if I were you, I'd at least make rich kids and people who have repeats pay for a re-install, installation of a router with a firewall if they don't have one, and setting up and training them to use a non-admin user account.
I'd be pushing them to get off MSWindows, too.
It's a game of odds, but I'd be trying to get my customers to play the better odds.
Come to think of it, a bigger question than whether they can make an exploit for PPC Macs (assuming the firmware is fat or something, I suppose), is whether they expect to be able to build an exploit that will work on openbsd.
I think that's what the specs are on the new silicon.
Anyway, Motorola's group has demonstrated non-interference at quite high bandwidth useage. Sure, there's a limit there somewhere, but there's a lot more headroom.
Does anybody mention whether this exploit works on PPC? (Did I miss that?)
If a company's tech support should be berated for buying gen 1 macs, should Apple be berated for failing to continue to sell non-gen-1 macs during the transition?
Or, indeed, for not simply introducing the iNTEL lines and keeping the PPC lines going.
Yes, the market would have supported that.
One problem, of course, is that Apple would have had to keep the lines up to date in the year before the "switch". No complaints about fake unavailability.
but iNTEL is trying to screw that up.
Motorola's UWB would fix that, but Steve bought the other roadmap.
Most of the problems with electronic voting machines are getting better attention this time around, but I still don't see much attention given to the problem that, for me, kills the whole idea of electronic voting, paper trail or otherwise.
We know that a well aimed antenna of appropriate characteristics can steal the data being typed at the typical keyboard.
What is to prevent the engineer who designs the motherboard from adding an innocuous physical loop in a data line somewhere and a carefully obscured bit of code that pumps every vote out that loop?
Then you have a few teenage geeks on the local political machine's payroll skateboarding and listening on AM radios outside the polling place, and one of those little cameras you can buy for about $35 these days focused on the voting booths, and the boss sends somebody around to offer a little education to those who voted wrong in the last election.
With a little social engineering, most of the recievers of the education will not even be aware that their vote was know, only that some influential friend is offering them political opinion that sounds kind of persuasive. And you don't have to educate the whole group, just those who seem respected in general.
I'm in favor of electronic tabulation, as long as the tabulation system doesn't force a design decision that makes it hard for the voter to check his or her vote. But the tabulation must be done after the ballot has been sequence-washed in the locked ballot box. And there should be a required hand tabulation, at the polling place, after the polls close, and before the election judges go home.
And no receipts, of course, no external paper trail that could be walked backwards in sequence in some dustly closet somewhere.
(Part of me sometimes wants to use random sequence numbers to make sure that the ballots in the box are the ones the judges had to pass out to the voters, but I have never been able to break the problem of walking the sequence backwards.)
one of the linux based systems. Seriously.
/olddata partition so the old drive can be saved as backup.
Buy them a new HD for the Linux, swap the HDs so you have the original safe-and-sound, and install, what, RH? SuSE? Ubuntu or Knoppix?
Show them where all the software they will use instead of the Microsilt is and show them how to do what they want to do. (Firefox, one of a couple of options on e-mail, openoffice?)
Hang the original HD off as a slave and set it up so they can mount it read-only and get at their old data. Or maybe copy the old data to a special
Make a date once or twice a week to come show them how to do what they can't figure out. You need the excuse to visit anyway, and you'll find after the second week that you actually do visit more than do geekly things.
Sounds great.
Especially great for you because you're going to be back in another month to six months to do it again.
Well, let's see.
Yeah, I admit, it was funky, although logical in a kind of twisty way, when Apple chose that paradigm.
What metaphor should they have chosen?
A picture of a cowboy getting off his horse? (un-mount. Get it?)
uhm, uhm, uhm, a picture of a mainframe tech pulling a tape off a tape drive?
(And how does one tell an icon representing mount from umount?)
A picture of a folder falling off the desk? Or the folder being moved from the desk to a filing cabinet? Well, how about the cabinet itself being wheeled into the safe? Or, maybe, wheeled out the front door?
The only decent idea I could come up with back then was having a duplicate trash folder on the desktop, with the icon changed to an open door or window.
Something to represent off-line?
Well, trash is off-line.
An open door or window also might invoke off-line.
Now that the descendents of boom-boxes are common small appliances even in less developed countries (yeah, less than what, and in what ways), the eject button ideograph makes a good descriptive image, too.
There were some (3rd party) system extensions that allowed one to change the icon on the fly -- when you started to drag the icon of a removable volume on the desktop, the trash icon changed to an icon of the user's choice. Common choices for the alternative icons were open windows and doors, and also that eject button image.
(I didn't like extensions multiplying like rabbits, and I didn't mind the trash metaphor, so I never even bothered keeping the duplicate trash with a different icon.)
So, now, in Mac OS X, when you start to drag the icon of a volume on the desktop, the trash icon changes to that eject-button ideograph. Where's the beef?
(I did note that dragging a volume icon from that panel on the left of the metal Finder window does not change the trash icon. I could presume that preparing the puff-of-smoke swallows the event?)
the same class of activity as bribing the hardware companies to put MSWxxx in every box sold?