I suspect that you haven't lived in California for very long. "Cal" or "California" refers to UC Berkeley, the original UC. I agree with you somewhat, but millions have gotten used to calling it that. And it isn't the only state with multiple state run universities to adopt that terminology -- Missouri (or "Missou") is another example...
You don't appear familiar with SMTP either. Bouncing (as opposed to an SMTP level rejection code) is to be avoided at all costs, because you end up sending the entire e-mail message back to what could, and is very likely, a forged address. And besides the social aspects of this, you've now wasted your bandwidth _twice_ (once accepting the entire e-mail, and again transmitting the backscatter e-mail) and now the unwitting victim of the address joe job gets his bandwidth wasted too, at which point he may complain and accuse *you* of sending spam -- all because you're a nice guy. (taking a deep breath now) Have I mentioned yet that some spammers use this method to relay spam?
You're better off sending a friendly message to the published address of the system administrator than scaring some random user. Sometimes, you might be better off not sending anything at all.
Every message *received* needs to be run through an expensive cryptographic routine. If you have high incoming mail volume, just watch your server load skyrocket when DK/DKIM is turned on. You also have to completely accept the entire message before DKIM can be used. With SPF, you can simply reject after the envelope-sender is specified and before the headers and data.
The people behind me don't like this, which I don't understand, because they want to race to the red light, brake the last 20-50 feet, and then start up from 0mph again. They are only wasting their gas and wearing out their brakes fasters, while not getting their any earlier.
Believe me, I perfectly understand the idealism here. However, many intersections with stoplights are outfitted with wire loops placed just behind the crosswalk lines. These same intersections are not only timed. Rather, they are also controlled by whether or not a car rolls up to the wire loop, and then a timer may kick in. The frustrating part is the intersection at a busy expressway and a smaller avenue that has a left-turn lane configured with a wire loop. Many times I have to roar up to the intersection quickly just to avoid idling 5 minutes in the left-turn lane waiting for the intersection to cycle again because I didn't hit the wire loop in time to trigger the green arrow! (Combine that mistake with a light-rail crossing for the potential of adding yet another 5 minutes to your idle time because the light-rail tripped its sensor at the last possible moment, thus resetting the entire cycle.)
There are many intersections in my city where the light just simply will not change from red to green unless a car rolls up to it and stops. Whether one lazily coasts or roars up to the intersection, as long as that person is the first, both actions will result in the same average idling time, although roaring up will still decrease your travel time.
You may not have lights that work this way (or you have just not noticed, or maybe you never have any time constraints and don't care), but I've been stuck behind many a driver who shares your philosophy and applies it unerringly, which, with these intersections, just causes us to wait 5 minutes more per block. If I, you, or someone else had been able to get the intersection just 10 seconds sooner, you would not have had to wait another 2 - 5 minutes for a green. At that point it becomes simple math: I can get across the city in 10 minutes if I trip the sensors at the right moment, or I can get across in 45 if I don't worry about it. I won't even get into the social or safety aspects of coasting at 5 - 10 mph for the last 500+ feet.
Aside from that, I try to coast and buffer my distance to allow for more even acceleration during stop-and-go, but there's also only so much one can do without letting people fill the gap for you, putting one even further behind with each car. A human driver must be intelligent too and vary the strategies for the driving conditions.
I believe it should. Reading all the comments so far, I've found out there's a feature-lacking controller chipset that at least one motherboard manufacturer uses without labelling this boot "feature" in a clear way on the packaging (without having to break the seals). I do buy motherboards on occasion, and I sure would have been frustrated to find this out on my own. If this is a new trend, then I prefer to hear about these kinds of issues beforehand.
Many times, what one thinks is a trend or a common way of thinking is news to everybody else. I had one slashdotter reply to me not long ago saying that IPMI was a standard now. Funny how that is, since I deal with Sun, HP, and IBM servers, and none of them use Intel's IPMI spec, at least as far as remote management is concerned. I don't think he meant to troll, I just think he got caught up in his own corner -- as probably happens to me in other areas too.
To me, this type of discussion is valuable. Many (most? almost all?) people still use PATA devices, and PATA devices are still being sold right alongside the SATA devices (and still possibly in greater quantities for PATA). There are a lot of people affected by this "trend" and possibly directly affected by this chipset.
a $20,000 projector Try $2500 for 1080p (this was over a year ago). And it's been done. I think the screen is currently set to around 108in. diagonal. The limit was the size of the bolt of fabric, but the projector could go bigger.
I haven't seen IPMI yet on HP server hardware. They use iLO. And iLO can lock up too. BTW, iLO isn't scriptable via a terminal session, and it didn't look like IPMI provides this either when I skimmed the website. Don't knock a remotely managed power strip until you try it.
As far as IPMI becoming an industry standard, I haven't seen IPMI on Sun or IBM either.
How do they plan on making that easy on an OS that needs regular attention? There are remotely managed power strips for the rackmounts. Also, a blade chassis has this capability on its own. With PXE and storage arrays, it becomes a matter of hardware just dying -- which can happen to any OS.
I have no problem with the gist of your argument, but I'm unsure as to your example: In northern california, we could really use a light rail system, as there are a lot of people who commute all the way to san francisco.
Please be more specific as to where you live. There are Amtrak commuter trains from the South Bay (as far south as Gilroy) and as far east as Sacramento. In the East Bay and Peninsula there is also BART. These all go to San Francisco. Perhaps you meant from the North Bay (Sonoma, Napa, etc.)?
Of course, I feel I should tell you (or maybe to inform others planning such) that any regular commute from the Central Valley (Sacramento, Tracy, Redding, etc.) is just absolutely insane, and if you're stuck, I really really feel sorry for you.
You're not having a problem with resolution. It has nothing to do with 1200x800 or any other screen resolution. Instead, you're having trouble reading the text because the font size is too small.
I run my own domains and my own squirrelmail installation as well. The company I work for does not filter it out, nor do I think they filter much of anything out or have any plans in the near future. I would like to think that my company trusts its employees' intelligence somewhat. There are of course network firewalls, virus scanners, and spam filters, for example. IT here are just not completely BOfH.
My personal e-mail is sent via my personal e-mail server, and corporate e-mail is over the corporate e-mail server. I don't mix the two, and I nudge my friends into doing the same. As far as my privacy, my personal e-mail is read and sent via SSL. (Oh, I know, someone might say "but smtp is transmitted in the clear." And I say, right, but my inbox in aggregate is encrypted between my server and my web browser, which I consider a far easier and more desirable target for any snooping -- not to mention that my MTA will encrypt its smtp sessions (and does frequently) with any other MTA that supports this.)
I keep my corporate and personal lives separated and don't abuse the network. Maybe, just maybe, my company's IT sees wisdom in this and will continue to allow this to happen.
How about at a large global company? Is that good enough?
My group in particular uses it to share files to Windows XP, 2000, 2003. The same server (Linux based) is also used for NFS for the other OSes we have. The file share is visible company-wide, since there are execs and other groups that need important files from it periodically. We generally don't have problems with it. Its current uptime is 90 days (power outage 90 days ago). The Windows servers don't even stay up for more than a couple of weeks (never mind not being able to serve to Unix and Unix-clones).
My group is not supporting 1000 desktops all constantly mounting/reading/writing (we're not in a support role), but when it needs to work, it does, and we use it every day.
All of your backup *worries* vanish, I said. If you have a storage array, you're likely already backing up all of the LUNs to tape.
With iSCSI or FC you can always mount the LUN read-only, whether clone or not. File-by-file backups only work when the file isn't open read/write anyway -- so I think you'd have the same problem with data integrity at that point.
But my main point is that this can all be off-loaded somewhere else, and doesn't need to be on the user's desktop.
Admittedly, this is the higher-end solution, but since you have 3500 desktops, I don't think it's unreasonable to think you already have or can get the infrastructure.
Using iSCSI or fibre channel, configure the NIC or HBA to boot from a pre-assigned lun. All of your backup worries vanish, because you are already backing up your storage arrays, and there's no local disk to fail. At the very least, there's disk redundancy.
Taking it even further, make all these desktops 1Us in a data center and use an Avocent system (or similar) for a KVM console at the user's desk. Now you have the best of both worlds: a computer dedicated to your user, but physically untouchable; and centralized backup, control, and troubleshooting for the admin.
I knew I was buying a new system design and there would be bugs, but I would expect Mr. Jobs to have at least some modicum of professional ethics and be up front about MAJOR problems so people can make informed choices.
I'm sure that this bug will have been fixed two weeks before the report.
Slashdot Mirror
California isn't a university. It is a state.
I suspect that you haven't lived in California for very long. "Cal" or "California" refers to UC Berkeley, the original UC. I agree with you somewhat, but millions have gotten used to calling it that. And it isn't the only state with multiple state run universities to adopt that terminology -- Missouri (or "Missou") is another example...
echo check > /sys/block/md1/md/sync_action
If it is a Linux server, you're already using mdadm, which has a monitoring daemon with e-mail notification.
You don't appear familiar with SMTP either. Bouncing (as opposed to an SMTP level rejection code) is to be avoided at all costs, because you end up sending the entire e-mail message back to what could, and is very likely, a forged address. And besides the social aspects of this, you've now wasted your bandwidth _twice_ (once accepting the entire e-mail, and again transmitting the backscatter e-mail) and now the unwitting victim of the address joe job gets his bandwidth wasted too, at which point he may complain and accuse *you* of sending spam -- all because you're a nice guy. (taking a deep breath now) Have I mentioned yet that some spammers use this method to relay spam?
You're better off sending a friendly message to the published address of the system administrator than scaring some random user. Sometimes, you might be better off not sending anything at all.
Every message *received* needs to be run through an expensive cryptographic routine. If you have high incoming mail volume, just watch your server load skyrocket when DK/DKIM is turned on. You also have to completely accept the entire message before DKIM can be used. With SPF, you can simply reject after the envelope-sender is specified and before the headers and data.
Good one! :)
Especially the violent, bullying type.
Believe me, I perfectly understand the idealism here. However, many intersections with stoplights are outfitted with wire loops placed just behind the crosswalk lines. These same intersections are not only timed. Rather, they are also controlled by whether or not a car rolls up to the wire loop, and then a timer may kick in. The frustrating part is the intersection at a busy expressway and a smaller avenue that has a left-turn lane configured with a wire loop. Many times I have to roar up to the intersection quickly just to avoid idling 5 minutes in the left-turn lane waiting for the intersection to cycle again because I didn't hit the wire loop in time to trigger the green arrow! (Combine that mistake with a light-rail crossing for the potential of adding yet another 5 minutes to your idle time because the light-rail tripped its sensor at the last possible moment, thus resetting the entire cycle.)
There are many intersections in my city where the light just simply will not change from red to green unless a car rolls up to it and stops. Whether one lazily coasts or roars up to the intersection, as long as that person is the first, both actions will result in the same average idling time, although roaring up will still decrease your travel time.
You may not have lights that work this way (or you have just not noticed, or maybe you never have any time constraints and don't care), but I've been stuck behind many a driver who shares your philosophy and applies it unerringly, which, with these intersections, just causes us to wait 5 minutes more per block. If I, you, or someone else had been able to get the intersection just 10 seconds sooner, you would not have had to wait another 2 - 5 minutes for a green. At that point it becomes simple math: I can get across the city in 10 minutes if I trip the sensors at the right moment, or I can get across in 45 if I don't worry about it. I won't even get into the social or safety aspects of coasting at 5 - 10 mph for the last 500+ feet.
Aside from that, I try to coast and buffer my distance to allow for more even acceleration during stop-and-go, but there's also only so much one can do without letting people fill the gap for you, putting one even further behind with each car. A human driver must be intelligent too and vary the strategies for the driving conditions.
He wanted half the price of a house
Maybe in 1980. $50,000 isn't even a decent down payment for many houses these days.
Firstly, should this really be posted on /. ?
I believe it should. Reading all the comments so far, I've found out there's a feature-lacking controller chipset that at least one motherboard manufacturer uses without labelling this boot "feature" in a clear way on the packaging (without having to break the seals). I do buy motherboards on occasion, and I sure would have been frustrated to find this out on my own. If this is a new trend, then I prefer to hear about these kinds of issues beforehand.
Many times, what one thinks is a trend or a common way of thinking is news to everybody else. I had one slashdotter reply to me not long ago saying that IPMI was a standard now. Funny how that is, since I deal with Sun, HP, and IBM servers, and none of them use Intel's IPMI spec, at least as far as remote management is concerned. I don't think he meant to troll, I just think he got caught up in his own corner -- as probably happens to me in other areas too.
To me, this type of discussion is valuable. Many (most? almost all?) people still use PATA devices, and PATA devices are still being sold right alongside the SATA devices (and still possibly in greater quantities for PATA). There are a lot of people affected by this "trend" and possibly directly affected by this chipset.
a $20,000 projector
Try $2500 for 1080p (this was over a year ago). And it's been done. I think the screen is currently set to around 108in. diagonal. The limit was the size of the bolt of fabric, but the projector could go bigger.
I haven't seen IPMI yet on HP server hardware. They use iLO. And iLO can lock up too. BTW, iLO isn't scriptable via a terminal session, and it didn't look like IPMI provides this either when I skimmed the website. Don't knock a remotely managed power strip until you try it.
As far as IPMI becoming an industry standard, I haven't seen IPMI on Sun or IBM either.
How do they plan on making that easy on an OS that needs regular attention?
There are remotely managed power strips for the rackmounts. Also, a blade chassis has this capability on its own. With PXE and storage arrays, it becomes a matter of hardware just dying -- which can happen to any OS.
I have no problem with the gist of your argument, but I'm unsure as to your example:
In northern california, we could really use a light rail system, as there are a lot of people who commute all the way to san francisco.
Please be more specific as to where you live. There are Amtrak commuter trains from the South Bay (as far south as Gilroy) and as far east as Sacramento. In the East Bay and Peninsula there is also BART. These all go to San Francisco. Perhaps you meant from the North Bay (Sonoma, Napa, etc.)?
Of course, I feel I should tell you (or maybe to inform others planning such) that any regular commute from the Central Valley (Sacramento, Tracy, Redding, etc.) is just absolutely insane, and if you're stuck, I really really feel sorry for you.
You're not having a problem with resolution. It has nothing to do with 1200x800 or any other screen resolution. Instead, you're having trouble reading the text because the font size is too small.
I run my own domains and my own squirrelmail installation as well. The company I work for does not filter it out, nor do I think they filter much of anything out or have any plans in the near future. I would like to think that my company trusts its employees' intelligence somewhat. There are of course network firewalls, virus scanners, and spam filters, for example. IT here are just not completely BOfH.
My personal e-mail is sent via my personal e-mail server, and corporate e-mail is over the corporate e-mail server. I don't mix the two, and I nudge my friends into doing the same. As far as my privacy, my personal e-mail is read and sent via SSL. (Oh, I know, someone might say "but smtp is transmitted in the clear." And I say, right, but my inbox in aggregate is encrypted between my server and my web browser, which I consider a far easier and more desirable target for any snooping -- not to mention that my MTA will encrypt its smtp sessions (and does frequently) with any other MTA that supports this.)
I keep my corporate and personal lives separated and don't abuse the network. Maybe, just maybe, my company's IT sees wisdom in this and will continue to allow this to happen.
(message captcha: paranoia)
How about at a large global company? Is that good enough?
My group in particular uses it to share files to Windows XP, 2000, 2003. The same server (Linux based) is also used for NFS for the other OSes we have. The file share is visible company-wide, since there are execs and other groups that need important files from it periodically. We generally don't have problems with it. Its current uptime is 90 days (power outage 90 days ago). The Windows servers don't even stay up for more than a couple of weeks (never mind not being able to serve to Unix and Unix-clones).
My group is not supporting 1000 desktops all constantly mounting/reading/writing (we're not in a support role), but when it needs to work, it does, and we use it every day.
I tuned out when he called "A Clockwork Orange" garbage.
All of your backup *worries* vanish, I said. If you have a storage array, you're likely already backing up all of the LUNs to tape.
With iSCSI or FC you can always mount the LUN read-only, whether clone or not. File-by-file backups only work when the file isn't open read/write anyway -- so I think you'd have the same problem with data integrity at that point.
But my main point is that this can all be off-loaded somewhere else, and doesn't need to be on the user's desktop.
Admittedly, this is the higher-end solution, but since you have 3500 desktops, I don't think it's unreasonable to think you already have or can get the infrastructure.
Using iSCSI or fibre channel, configure the NIC or HBA to boot from a pre-assigned lun. All of your backup worries vanish, because you are already backing up your storage arrays, and there's no local disk to fail. At the very least, there's disk redundancy.
Taking it even further, make all these desktops 1Us in a data center and use an Avocent system (or similar) for a KVM console at the user's desk. Now you have the best of both worlds: a computer dedicated to your user, but physically untouchable; and centralized backup, control, and troubleshooting for the admin.
Oh crap! Maybe not!
"...feel pretty fscking real to you too. ..."
this is the internet, you can say fucking.
This is Slashdot, where we also get computer references.
It's not about the punchline. We all know the punchline. It's all about the setup.
I knew I was buying a new system design and there would be bugs, but I would expect Mr. Jobs to have at least some modicum of professional ethics and be up front about MAJOR problems so people can make informed choices.
I'm sure that this bug will have been fixed two weeks before the report.
1024 Internets