If you sweat riding at an equivilent rate at a bicycle you seriously need the exercise. Hell, even when I first started cycling I was doing a 12km commute in about a half hour without much difficulty (and at the time I was considerably overweight).
Why are they comparing the Atom against the L2100? That's from the desktop line of Via Nano processors. Replace the L2100 with the U2400 and you drop from peak draw of 25W to 8W and idle draw of 500mW to 100mW.
I'm also curious about the idle draw. There are systems out there based on the same chipset (CN896) that pull 10-15W *under load*. Given the negligable idle draw of the processor itself it seems curious it should be that high, unless the reference board is simply horribly inefficient. But again, in the market the Atom is aiming the VX800U (with a peak draw of 3.5W) would seem a far more likely pairing. Of course for this test Intel is also pairing with a less efficient chipset, so it's not the fault of the reviewer.
Erm, the Xserve RAID was discontinues earlier this year and XSAN is a seperate product (and just a rebadge of a Quantum offering) so it hardly counts toward what Mac OS X Server is.:)
Funny, from a desktop perspective I went Slackware -> Red Hat -> Fedora -> Ubuntu -> CentOS because HOLY CRAP an Ubuntu upgrade totally hosed my system and ended up with some thoroughly fucked dependency issues.:) And from a server perspective I went from Solaris -> Debian -> CentOS because the idiots at Debian release a 3.0 with a known broken PHP package and then proceeded to leave it broken for six months./counterrant
Bonus question - is the Debian based answer going to be any easier than "yum update firefox"? (That's exactly the command I used to upgrade an old CentOS 5 box I had to FF3)
I've built literally thousands of packages. RPM is just fine. Some distributions and some repos are fucked (which is just as true for dpkg) but the package format is just fine.
That's no excuse for not testing a change after you've put it into production. Presumably the company probably has at least one secondary nameservers a well. No way in hell should those have proceeded until after the pilot upgrade was complete.
(And seriously - virtualization is free on every major platform. If you can't get test equipment install a fargin' VM on your desktop.)
2) The admin installed "caching-nameserver", then configured his install to act far outside the default.
There's no "caching-nameserver" package - just bind, which happens to come with a default config. This was certainly a mistake on Red Hat's part, but yeah - one that any competent admin certainly should have caught. (Not having test environments is a pathetic excuse when your platform comes with virtualization out of the box and not testing immediately after an upgrade - and before upgrading secondaries - is inexcusable.)
Misleading headline aside, this is the sort of thing that makes me mostly ignore Ubuntu:
And that we don't say if GTK +3 is released it will be API/ABI-stable forever, cause it won't be perfect. So we might need to say: Lets GTK+ 3 iterate for a year or two and then make the API/ABI-commitment and drop the commitment on GTK+ 2.
A year or two of unstable interfaces is not going to win over developers or users. Thankfully the GTK+ developers actually understand the value of stable interfaces and have managed to maintain stability in the current branch even though 2.0 wasn't perfrect.
Net booting is only one aspect of provisioning. What about tracking (servers, virtual machines, assets, images, configs, etc)? Or adding hosts to DNS and DHCP configs? Or keeping machines synced after the initial install? Or password and user management?
If you were an energy company would you want to gamble that the government wouldn't impose new regulations down the line impacting projected profitability? Or even that construction or operation wouldn't be halted altogether by new legislation?
Like it or not a commitment of cooperation (or at least non-interference) from the government is the only way new nukes will be built.
There was also a fairly high failure rate on deliveries to their SMS gateway as well. In any case, regardless of the source of their problems it disqualified them as a carrier for us.
Re:Anything else out there?
on
The State of X.Org
·
· Score: 2, Insightful
Alrightly then. I'm not one to waste my time arguing with irrational stereotypes.
Re:Finally, developers' ignorance and childish
on
The State of X.Org
·
· Score: 3, Informative
Erm, no. X-SHM came from MIT, not Sun, and is a mechanism for bitmaps on the same machine to be stored in shared memory segments.
There have been several proprietary shared memory transports added by vendors over the years, including Sun, so the poster is correct. And once upon a time Precision Insight wrote an implementation for XFree86 as well.
However the conclusion after benchmarking various operations was that there was little to no benefit over the unix domain socket transport since it doesn't speed up render-bound operations at all the most significant transport-bound operations are already optimized using the SHM extension. Though performance was improved slightly on some hardware the recommendation after initial implementation and optimization was to abandon the effort.
Re:Finally, developers' ignorance and childish
on
The State of X.Org
·
· Score: 1
Bitmaps are already stored in shared memory on local machines thanks to the SHM extension.
A Toyota Corolla is also without competeing forks. Doesn't mean there isn't competition.
Re:Anything else out there?
on
The State of X.Org
·
· Score: 3, Insightful
Considering Linux the kernel targets everything from the embedded space to the mainframe, I'd say they are.
If you're talking about the desktop space, there's really little to nothing that a user interacts with that wouldn't run on any of those platforms. Linux just happens to have the most traction (which has a multiplying effect since it encourages vendor support and attracts new developers).
Umm... heavier? Have you actually looked at the weight on mini-vans? Dodge Grand Caravan has a curb weight starting at 4321, Honda Odyssey at 4385, Hyundai Entourage at 4400, Toyota Sienna at 4398 and Nissan Quest at 4293. Moving over to SUVs we find the Dodge Journey at 3081, Honda CR-V at 3289, Hyundai Tuscon at 3240, Toyota Rav4 at 3300 and Nissan Rogue at 3280.
The trend in SUVs for years has been towards smaller lighter unibody models. If you look at the top twenty selling passenger vehicles the only SUVs you'll see are small, light and relatively fuel efficient - the CR-V (20/27mpg), the Rav4 (21/27mpg) and Ford Escape (22/28mpg).
But hey, stick with the stereotypes. They seem to work for you.
These problems were reported by everyone on my team. AT&T tried swapping us completely new phones. Then a new model of phone. Then a second new model of phone. Then we switched to sprint.
The relative quality of the cellular providers varys wildly depending on location. In my area I would rate AT&T as the absolute bottom of the barrel by a wide margin - dropped calls, people being dropped directly into voice mail despite my phone having signal, ludicrous failure rate on incoming SMS. On the other hand I've had Verizon for about six years now and Sprint for four. No problems with either one.
Slashdot Mirror
Why on earth would you need to courier deliver a certificate?
If you sweat riding at an equivilent rate at a bicycle you seriously need the exercise. Hell, even when I first started cycling I was doing a 12km commute in about a half hour without much difficulty (and at the time I was considerably overweight).
Why are they comparing the Atom against the L2100? That's from the desktop line of Via Nano processors. Replace the L2100 with the U2400 and you drop from peak draw of 25W to 8W and idle draw of 500mW to 100mW.
I'm also curious about the idle draw. There are systems out there based on the same chipset (CN896) that pull 10-15W *under load*. Given the negligable idle draw of the processor itself it seems curious it should be that high, unless the reference board is simply horribly inefficient. But again, in the market the Atom is aiming the VX800U (with a peak draw of 3.5W) would seem a far more likely pairing. Of course for this test Intel is also pairing with a less efficient chipset, so it's not the fault of the reviewer.
Erm, the Xserve RAID was discontinues earlier this year and XSAN is a seperate product (and just a rebadge of a Quantum offering) so it hardly counts toward what Mac OS X Server is. :)
Funny, from a desktop perspective I went Slackware -> Red Hat -> Fedora -> Ubuntu -> CentOS because HOLY CRAP an Ubuntu upgrade totally hosed my system and ended up with some thoroughly fucked dependency issues. :) And from a server perspective I went from Solaris -> Debian -> CentOS because the idiots at Debian release a 3.0 with a known broken PHP package and then proceeded to leave it broken for six months. /counterrant
Bonus question - is the Debian based answer going to be any easier than "yum update firefox"? (That's exactly the command I used to upgrade an old CentOS 5 box I had to FF3)
I've built literally thousands of packages. RPM is just fine. Some distributions and some repos are fucked (which is just as true for dpkg) but the package format is just fine.
s/facts/opinions/
HTH. HAND.
That's no excuse for not testing a change after you've put it into production. Presumably the company probably has at least one secondary nameservers a well. No way in hell should those have proceeded until after the pilot upgrade was complete.
(And seriously - virtualization is free on every major platform. If you can't get test equipment install a fargin' VM on your desktop.)
2) The admin installed "caching-nameserver", then configured his install to act far outside the default.
There's no "caching-nameserver" package - just bind, which happens to come with a default config. This was certainly a mistake on Red Hat's part, but yeah - one that any competent admin certainly should have caught. (Not having test environments is a pathetic excuse when your platform comes with virtualization out of the box and not testing immediately after an upgrade - and before upgrading secondaries - is inexcusable.)
Misleading headline aside, this is the sort of thing that makes me mostly ignore Ubuntu:
A year or two of unstable interfaces is not going to win over developers or users. Thankfully the GTK+ developers actually understand the value of stable interfaces and have managed to maintain stability in the current branch even though 2.0 wasn't perfrect.
Net booting is only one aspect of provisioning. What about tracking (servers, virtual machines, assets, images, configs, etc)? Or adding hosts to DNS and DHCP configs? Or keeping machines synced after the initial install? Or password and user management?
If you were an energy company would you want to gamble that the government wouldn't impose new regulations down the line impacting projected profitability? Or even that construction or operation wouldn't be halted altogether by new legislation?
Like it or not a commitment of cooperation (or at least non-interference) from the government is the only way new nukes will be built.
There was also a fairly high failure rate on deliveries to their SMS gateway as well. In any case, regardless of the source of their problems it disqualified them as a carrier for us.
Alrightly then. I'm not one to waste my time arguing with irrational stereotypes.
Erm, no. X-SHM came from MIT, not Sun, and is a mechanism for bitmaps on the same machine to be stored in shared memory segments.
There have been several proprietary shared memory transports added by vendors over the years, including Sun, so the poster is correct. And once upon a time Precision Insight wrote an implementation for XFree86 as well.
However the conclusion after benchmarking various operations was that there was little to no benefit over the unix domain socket transport since it doesn't speed up render-bound operations at all the most significant transport-bound operations are already optimized using the SHM extension. Though performance was improved slightly on some hardware the recommendation after initial implementation and optimization was to abandon the effort.
Bitmaps are already stored in shared memory on local machines thanks to the SHM extension.
A Toyota Corolla is also without competeing forks. Doesn't mean there isn't competition.
Considering Linux the kernel targets everything from the embedded space to the mainframe, I'd say they are.
If you're talking about the desktop space, there's really little to nothing that a user interacts with that wouldn't run on any of those platforms. Linux just happens to have the most traction (which has a multiplying effect since it encourages vendor support and attracts new developers).
The vast majority of SUVs are unibody as well.
Umm... heavier? Have you actually looked at the weight on mini-vans? Dodge Grand Caravan has a curb weight starting at 4321, Honda Odyssey at 4385, Hyundai Entourage at 4400, Toyota Sienna at 4398 and Nissan Quest at 4293. Moving over to SUVs we find the Dodge Journey at 3081, Honda CR-V at 3289, Hyundai Tuscon at 3240, Toyota Rav4 at 3300 and Nissan Rogue at 3280.
The trend in SUVs for years has been towards smaller lighter unibody models. If you look at the top twenty selling passenger vehicles the only SUVs you'll see are small, light and relatively fuel efficient - the CR-V (20/27mpg), the Rav4 (21/27mpg) and Ford Escape (22/28mpg).
But hey, stick with the stereotypes. They seem to work for you.
These problems were reported by everyone on my team. AT&T tried swapping us completely new phones. Then a new model of phone. Then a second new model of phone. Then we switched to sprint.
The relative quality of the cellular providers varys wildly depending on location. In my area I would rate AT&T as the absolute bottom of the barrel by a wide margin - dropped calls, people being dropped directly into voice mail despite my phone having signal, ludicrous failure rate on incoming SMS. On the other hand I've had Verizon for about six years now and Sprint for four. No problems with either one.
No girlfriend, and my wife is as disinterested in Apple products as I am. :)
so no one on slashdot is really interested in the low end machine other than to talk about it's price
Sure we are. We're just not the ones saying how much better more expensive machines are.
Nah, it's Perl for people who like Smalltalk.