Right. But only a certain percentage is willing to stick with Apple when there's inconvenience associated with doing that. Also, a lot of people had bad experiences (eg, the iBooks) and have had their tolerance lowered.
It would be stupid to not throw some information out there. Now, many people will simply wait for a new iMac, now that they know the new one will be a G5. Without that information, they'd ask themselves why they should pass up on alternatives when the new iMac may or may not meet their requirements.
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses (x) Mailing lists and other legitimate email uses would be affected ( ) No one will be able to find the guy or collect the money (x) It is defenseless against brute force attacks ( ) It will stop spam for two weeks and then we'll be stuck with it ( ) Users of email will not put up with it ( ) Microsoft will not put up with it ( ) The police will not put up with it (x) Requires too much cooperation from spammers ( ) Requires immediate total cooperation from everybody at once (x) Many email users cannot afford to lose business or alienate potential employers ( ) Spammers don't care about invalid addresses in their lists ( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it ( ) Lack of centrally controlling authority for email ( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses ( ) Asshats ( ) Jurisdictional problems ( ) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money ( ) Huge existing software investment in SMTP ( ) Susceptibility of protocols other than SMTP to attack ( ) Willingness of users to install OS patches received by email (x) Armies of worm riddled broadband-connected Windows boxes (x) Eternal arms race involved in all filtering approaches ( ) Extreme profitability of spam ( ) Joe jobs and/or identity theft ( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers ( ) Dishonesty on the part of spammers themselves (x) Bandwidth costs that are unaffected by client filtering ( ) Outlook
and the following philosophical objections may also apply:
(x) Ideas similar to yours are easy to come up with, yet none have ever been shown practical ( ) Any scheme based on opt-out is unacceptable ( ) SMTP headers should not be the subject of legislation ( ) Blacklists suck ( ) Whitelists suck ( ) We should be able to talk about Viagra without being censored ( ) Countermeasures should not involve wire fraud or credit card fraud ( ) Countermeasures should not involve sabotage of public networks (x) Countermeasures must work if phased in gradually ( ) Sending email should be free (x) Why should we have to trust you and your servers? ( ) Incompatiblity with open source or open source licenses ( ) Feel-good measures do nothing to solve the problem ( ) Temporary/one-time email addresses are cumbersome ( ) I don't want the government reading my email ( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(x) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it.
ksh isn't unfamiliar, but bash beats it pretty handily with features and in how easy it is to customize.
The trick is to LEAVE THE SHELL FOR ROOT ALONE. If you're logging in as a regular user, chances are everything is okay. If, say,/usr isn't mounted, then you're at the console fixing it (as sshd is in/usr/sbin), and likely can afford to log in as root just this once.
There's also a statically compile bash in packages, if you think that's necessary.
I probably ride pretty close to the zealot line, but I can give you some information:
Performance on UP systems is too close to call. They all "feel" the same.
It comes down to features. OpenBSD and FreeBSD have unbeatable server features. OpenBSD for the general security, FreeBSD for really killer things like jails.
I'm honestly not that impressed with any of them on the Desktop, I mostly use MacOS for that. I have a *nix workstation, that's mostly for programming work and it runs whatever is convenient. Windows, Linux, FreeBSD mostly. It varies.
This is why I have all my personal stuff on a fileserver, so I can nuke the whole hard drive every other week without losing anything but OS specific stuff.
Well, it won't hurt. I think they decided to take the plunge because of the dual-core CPUs starting to come out.
Re:Why it wasn't put in already
on
Hacking Quartz
·
· Score: 2, Insightful
Apple could always do what M$ do: release it as an unsupported PowerToy. That way, those of us who like (or need) virtual desktops can have them and those who like the way Expose works can stay with it. It seems silly not to if the API support is there.
I agree, but it's not the Apple Way to do that. Sometimes, the Apple Way leaves power users out in the cold.
note: Expose works even with virtual desktops, it's just restricted to the windows in a workspace.
Alternatively, why can't they make the API public and then let the community provide a solution?
As I said, then they'd have to subject it to continual testing as other parts of the OS changed. They could put a "volatile" warning on the API, but again, that's not the Apple Way.
Right now, if it breaks they can say "Hey, he reverse engineered our software to get that. We aren't responsible for maintaining it.".
I'm not apologising for them. They're being idiots, but I can at least understand them, and there's a logic to it.
Re:Why it wasn't put in already
on
Hacking Quartz
·
· Score: 4, Insightful
WHAT? THIS IS EXACTLY WHAT EXPOSE DOES -- SHOW/HIDE EVERYTHING WITH ONE CLICK.
What you're talking about -- granularly assigning arbitrary windows to a particular desktop set across application
You say that's what it does... but then you go on to admit it's not what he's trying to do. We can dance around the issue all you want, but what he's saying is that Expose doesn't help him with his workloads. His workloads are what he needs to do. Sure, he's not typical, but that just means Apple's solution doesn't work for him. He exists. Get over it.
This guy says he needs 11 desktops... that's probably dozens of windows, a lot of them are probably terminal windows, which look almost identical when they're zoomed out enough. Even with a 30" Apple Cinema Display, can you imagine how hard it would be to find the one he wants?
The Apple way of doing things doesn't scale well past the moderately used desktop system (eg, a significant but limited number of concurrent tasks). The OS can handle it easily, but the interface can't. In cases where you can do more with a Mac, it usually means using 3rd party software like this virtual desktop thing, or falling back on stuff that's available on any UNIX machine.
That's not a knock against Apple. They have the API for multiple desktops, and I'll bet they don't publish it just so they don't have to maintain the API eternally, and make their unit tests even bigger than they are. They have all the UNIX tools because they know sometimes people will need to fall back on something with no GUI front end. That makes everyone's life a lot easier, including mine.
Apple gives people enough so they can sort themselves out if the shiny happy GUI isn't good enough. Learn from them.
Our Internet use is not closely monitored. I've uploaded stuff like MP3s borrowed from officemates, and behind the encryption there's no way to tell what it is.
I could steal the source to all my company's software and related documentation on my USB key. Of course, I could upload it to my home computer or some other site with no USB key. Who could tell the difference with SSH?
Instead, they trust me. I signed the NDA and I honor it.
As I understand it, the point of lwkt is to maximize the benfit of CPU cache by keeping threads local to a given CPU. That's a slightly more batch oriented approach, and in SMP systems I think it will provide benefit for batch type jobs. But I think it will reduce the freedom of the kernel to run interactive stuff IMMEDIATELY, like Linux 2.6 and FreeBSD 5.x do now. They're both quite good at keeping interative tasks responsive.
I'm not an expert and it may actually increase performance because of the cache-- I don't know.
From what I've read though, I think that the overall DragonFlyBSD strategy has a credible chance of beating the performance of FreeBSD, Linux, and Solaris on SMP systems, especially for stuff like dynamic content and databases. I'm not saying it's a bad idea, I'm just saying that I can think of a few possible negative side effects.
I kinda think the lightweight kernel threads will make it worse at desktop performance than FreeBSD, as threads can't migrate to other CPUs as easily, but that's just speculation.
Even if you only count warranty repairs, this must have been costing Apple a fortune. What I can't figure out is how they failed to do something about it for that entire time. There were many revisions in that time.
No, there would be a class action suit, it would take years to work out, and everyone would hate them before it was over. Then people who'd had it happen more than once would SOL.
I have a ton of friends that have considered iBooks and ultimately decided not to get one because it was too risky. They saw me and everyone they know with an iBook constantly getting it repaired.
This is my first Apple computer. I had major problems with every OS version I used up to 10.3.3. I had 2 power adaptors die after a few weeks of normal use, I've had the logic board replaced 4 times, the CD-ROM died, the extra memory died, and the backlight on the display died.
The thing's been fine for a year now. But you can bet I'll never touch another Apple again. I've had too many failures in too many different ways for it to be anything other than poor quality assurance. I have had more problems with this computer than with every computer I've ever owned, even if you expand that to include every computer my parents and sibblings owned while I was living with them (14 total since 1989, 4 of those were laptops.).
I don't think describing UNIX as a language is as wrong as one would initially think. UNIX has a way of thinking and a way of doing things very firmly attached to it, just as human languages do.
What he got wrong (maybe intentionally) was how much UNIX can do. It's modular and extensible enough to do anything. But what it does happens in the UNIX way.
Slashdot Mirror
Right. But only a certain percentage is willing to stick with Apple when there's inconvenience associated with doing that. Also, a lot of people had bad experiences (eg, the iBooks) and have had their tolerance lowered.
When I said "alternatives", I meant "completely different computers, possibly from a completely different vendors".
It would be stupid to not throw some information out there. Now, many people will simply wait for a new iMac, now that they know the new one will be a G5. Without that information, they'd ask themselves why they should pass up on alternatives when the new iMac may or may not meet their requirements.
Well, they've been around for a year. Another 3 months won't be a problem.
But why do they need an icon?
This article advocates a
( ) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(x) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
(x) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
(x) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
(x) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
(x) Armies of worm riddled broadband-connected Windows boxes
(x) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
(x) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
(x) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(x) Countermeasures must work if phased in gradually
( ) Sending email should be free
(x) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(x) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
meh
/usr isn't mounted, then you're at the console fixing it (as sshd is in /usr/sbin), and likely can afford to log in as root just this once.
ksh isn't unfamiliar, but bash beats it pretty handily with features and in how easy it is to customize.
The trick is to LEAVE THE SHELL FOR ROOT ALONE. If you're logging in as a regular user, chances are everything is okay. If, say,
There's also a statically compile bash in packages, if you think that's necessary.
I probably ride pretty close to the zealot line, but I can give you some information:
Performance on UP systems is too close to call. They all "feel" the same.
It comes down to features. OpenBSD and FreeBSD have unbeatable server features. OpenBSD for the general security, FreeBSD for really killer things like jails.
I'm honestly not that impressed with any of them on the Desktop, I mostly use MacOS for that. I have a *nix workstation, that's mostly for programming work and it runs whatever is convenient. Windows, Linux, FreeBSD mostly. It varies.
This is why I have all my personal stuff on a fileserver, so I can nuke the whole hard drive every other week without losing anything but OS specific stuff.
Yeah. Fuck.
That pretty much means they'll switch to something else and it'll be even more annoying.
Well, it won't hurt. I think they decided to take the plunge because of the dual-core CPUs starting to come out.
Apple could always do what M$ do: release it as an unsupported PowerToy. That way, those of us who like (or need) virtual desktops can have them and those who like the way Expose works can stay with it. It seems silly not to if the API support is there.
I agree, but it's not the Apple Way to do that. Sometimes, the Apple Way leaves power users out in the cold.
note: Expose works even with virtual desktops, it's just restricted to the windows in a workspace.
Alternatively, why can't they make the API public and then let the community provide a solution?
As I said, then they'd have to subject it to continual testing as other parts of the OS changed. They could put a "volatile" warning on the API, but again, that's not the Apple Way.
Right now, if it breaks they can say "Hey, he reverse engineered our software to get that. We aren't responsible for maintaining it.".
I'm not apologising for them. They're being idiots, but I can at least understand them, and there's a logic to it.
WHAT? THIS IS EXACTLY WHAT EXPOSE DOES -- SHOW/HIDE EVERYTHING WITH ONE CLICK.
What you're talking about -- granularly assigning arbitrary windows to a particular desktop set across application
You say that's what it does... but then you go on to admit it's not what he's trying to do. We can dance around the issue all you want, but what he's saying is that Expose doesn't help him with his workloads. His workloads are what he needs to do. Sure, he's not typical, but that just means Apple's solution doesn't work for him. He exists. Get over it.
This guy says he needs 11 desktops... that's probably dozens of windows, a lot of them are probably terminal windows, which look almost identical when they're zoomed out enough. Even with a 30" Apple Cinema Display, can you imagine how hard it would be to find the one he wants?
The Apple way of doing things doesn't scale well past the moderately used desktop system (eg, a significant but limited number of concurrent tasks). The OS can handle it easily, but the interface can't. In cases where you can do more with a Mac, it usually means using 3rd party software like this virtual desktop thing, or falling back on stuff that's available on any UNIX machine.
That's not a knock against Apple. They have the API for multiple desktops, and I'll bet they don't publish it just so they don't have to maintain the API eternally, and make their unit tests even bigger than they are. They have all the UNIX tools because they know sometimes people will need to fall back on something with no GUI front end. That makes everyone's life a lot easier, including mine.
Apple gives people enough so they can sort themselves out if the shiny happy GUI isn't good enough. Learn from them.
Our Internet use is not closely monitored. I've uploaded stuff like MP3s borrowed from officemates, and behind the encryption there's no way to tell what it is.
I could steal the source to all my company's software and related documentation on my USB key. Of course, I could upload it to my home computer or some other site with no USB key. Who could tell the difference with SSH? Instead, they trust me. I signed the NDA and I honor it.
Wake me up when the iMac G5s get here.
As I understand it, the point of lwkt is to maximize the benfit of CPU cache by keeping threads local to a given CPU. That's a slightly more batch oriented approach, and in SMP systems I think it will provide benefit for batch type jobs. But I think it will reduce the freedom of the kernel to run interactive stuff IMMEDIATELY, like Linux 2.6 and FreeBSD 5.x do now. They're both quite good at keeping interative tasks responsive.
I'm not an expert and it may actually increase performance because of the cache-- I don't know.
From what I've read though, I think that the overall DragonFlyBSD strategy has a credible chance of beating the performance of FreeBSD, Linux, and Solaris on SMP systems, especially for stuff like dynamic content and databases. I'm not saying it's a bad idea, I'm just saying that I can think of a few possible negative side effects.
I kinda think the lightweight kernel threads will make it worse at desktop performance than FreeBSD, as threads can't migrate to other CPUs as easily, but that's just speculation.
I'm mostly just making fun of them so I make fun of someone other than Apple from time to time.
A pretty big minority said "What about thttpd?"? The official word is that the default will not be changed.
Of course, if you want to install it out of ports...
I dunno, biglock is the way to get it working. Portions of the kernel can then be multithreaded gradually over time.
Or who knows, they might decide to do it the DragonFly way.
These hackathons always scare me a bit. Major functionality has a habbit of going from non-existant to solid before it's over.
"It seems to be just with the iBooks; the other products are OK."
Except the iPod Minis which fail after a few weeks of normal use...
Even if you only count warranty repairs, this must have been costing Apple a fortune. What I can't figure out is how they failed to do something about it for that entire time. There were many revisions in that time.
No, there would be a class action suit, it would take years to work out, and everyone would hate them before it was over. Then people who'd had it happen more than once would SOL.
I have a ton of friends that have considered iBooks and ultimately decided not to get one because it was too risky. They saw me and everyone they know with an iBook constantly getting it repaired.
This is my first Apple computer. I had major problems with every OS version I used up to 10.3.3. I had 2 power adaptors die after a few weeks of normal use, I've had the logic board replaced 4 times, the CD-ROM died, the extra memory died, and the backlight on the display died.
The thing's been fine for a year now. But you can bet I'll never touch another Apple again. I've had too many failures in too many different ways for it to be anything other than poor quality assurance. I have had more problems with this computer than with every computer I've ever owned, even if you expand that to include every computer my parents and sibblings owned while I was living with them (14 total since 1989, 4 of those were laptops.).
You can still buy a new sparc machine. The only people that can buy new Alphas are people that have preexisting contracts to buy them.
I don't think describing UNIX as a language is as wrong as one would initially think. UNIX has a way of thinking and a way of doing things very firmly attached to it, just as human languages do.
What he got wrong (maybe intentionally) was how much UNIX can do. It's modular and extensible enough to do anything. But what it does happens in the UNIX way.