People buy computers to do things for them. Not so they can do things to computers. As more computing power becomes available, we should expect that software comes out of the box capable of doing more things with that power. These are great features for creating presentations, writing letters, looking for an old paper you wrote, and surfing the web, all of which already runs smoothly on most every ancient computer out there. I dare say that better UIs and cheaper cameras are making photo processing into the same den, and the system can also handle that fine and well.
Where Microsoft has really failed is at successfully offering distinctive versions. Its clear enough it was driven more by naive marketing than good product design. Home, Home premium, Business, Ultimate? The fact that many people have to read what's being offered in each and compare means they've already failed. They're treated as cubby holes with which to put in features and capture those who'd pay 400 for an operating system. It would have been wiser to offer Home, Business and Gamer. Gamers are the ones who're pissed about performance and obsess over free RAM and idle disk. They'll discount things like shadow volume copies, backup policies, or search indexing. They'll even disable GL window effects if it means degraded performance. So turn that shit off by default, give them an insightfully tuned computer out of the box, for what they want.
I can only imagine that Microsoft is trying to move the gamers off the PC and onto the 360, where they receive royalties for every game sold.
Actually, I think we do care about the rights to the recording, since their objection is that Harmonic's recording of their song sounds too much like theirs, even though they apparently paid for the rights to make a new recording of it. I think the best we can really say about this mess is that making music records is like making sausage.
Indeed. The purpose of salting and hashing is that they protect the passwords from the administrative staff, and anyone else who can historically see the data.
What's far more scary is the number of sites that want your email address as a user login. Imagine how many people use the same password across sites, including their email account...
Invite? They revel in it! They make a habit of publishing silly rebuttals to legal threats, and apparently their country of origin supports them to a surprising degree.
Search indexers hit every file once, most programs hit the same file over and over. The former is bad for cache, the latter is great.
AFAIK, Linux has a unified buffer cache. Meaning VM pressure will push block data out, and FS pressure will push VM out. The secondary effect is to nuke the file cache, but the big complaint people had was programs getting pushed out due to indexers. In effect, the cache is cleaned of any relevance, being "filled" with filesystem junk thanks to the poor locality of indexers. So you wake up and the GNOME libs all have to come back in, etc.
Free ram *is* wasted RAM, after the first few percentage points to deal with immediate allocation needs. It costs you the same to power RAM whether it holds meaningful information or not. So it might as well cache SOMETHING.
Unused RAM is wasted RAM. Presumably file system cache is filling up the space freed by things now in swap. It's a balance between using RAM for RAM and using it for faster disk read / writes. If the machine goes unused for a time, there shouldn't be any pressure either way. Linux machines used to have a small problem with search indexers running nightly and busting the cache by hitting every directory and file on disk.
Seriously though, swap is not a performance critical system anymore. By this I mean, while the existence of swap can be beneficial to system performance, the things that go into swap today rarely come out -- swapping is not the expected use case anymore. Therefore you can be as slow as you like with it. So basically, you shouldn't be worried about fragmentation either way.
Placement on disk also cares about the frequency and size of swap requests. If your caching system just pushed a little too close to the working set, then you'll have small requests infrequently, and the time will be dominated by seek, not throughput. If you're mostly just storing the unused 2/3rds of a DLL or startup code for a few kilo/megabytes more of FS cache, placement is also irrelevant. Only when you expect to actually have a working set larger than memory will placement really start to matter. Try measuring the activity of the swapfile during various activities. If you've got a gig or two of RAM, it shouldn't move much.
Really, ther's no need to measure average seek times and disk access metrics in order to optimize swap, though they're still interesting experiments for obsessive geeks.
I also think there's more to this than meets the eye, but not the same thing you do. Giving away the fact that he was in range for a firing solution on a carrier could be regarded as a serious tactical error by the Chinese captain. It would be far better to let the carrier group pass by, then slip off in silence and keep that knowledge secret. Letting the US Navy know they can do that will only make the US Navy work very hard to find a solution to that problem and negate that advantage. On the other hand, things nobody knows exist make poor deterrents. If you want Taiwan under control, currently it means going through several US fleet hulls. This sort of revelation can potentially end that policy.
Of course, Switzerland also has more social programs, along with free education. Meaning people who might be otherwise unemployed aren't even looking right yet. And the definition of unemployment is the percent of people who want work but can't find any.
No, it's like store brand shaving cream designed to mimic the branding of expensive shampoos, and placed nearby. In your example, there's at least a good chance you'll walk home with shampoo.
Except these are security convoys. They're not rushing off to find a terrorist. They're running security patrols or escorting foreign civilian traffic. I don't recall having to yield for a semi carrying food in the states. The reason they have to go fast is because if they stop, they'll get their asses trapped, and subsequently kicked, for venturing outside the security perimeter.
The US Army is great at fighting other Geneva Convention signers. But those ethics also form a weakness. If you're the sort of person who wants victory at all costs, I guess Bush's erosion of torture and other former ethics are a boon. The whole purpose of the DARPA project is to reduce the casulties in the event of an attack on a convoy (and probably to set up diversions).
* Application bundles - drag and drop install, removal. Ability to drag an.app to anywhere in the file system at any time. App resources all contained in the.app directory structure instead of scattered all over the file system Succinctly put, you don't really want that.
It's a lot of man hours to remove the LSB assumptions into the code base. Plus you'd have convince every upstream application that yours is the one true way, when they've already signed on. Ubuntu doesn't own the code they give to you, and they certainly don't command the people who did write the code. It'd be not only a lot of work now, but more work every release in the future to merge patches upstream refuses to accept. And it requires a lot of ugliness with shipping libraries (I'll cover that more in a moment) that have already been solved.
Moreover, it breaks security. Currently, every package within Ubuntu main is attended to by the security team. Even things as trivial as buffer overflows in a game's image handler will be addressed (in main). Simply discarding package management in favor of drag and dropping means discarding this universal security policy. So now every application has to duplicate update functionality, and do so securely.
It breaks efficiency. Firstly, you're effectively spreading libraries out on disk, meaning more seeks to navigate the directory structure, versus one for/lib. Secondly, OSX bundles usually either build libraries statically, or ship private libraries. The only truly shared libraries are the ones Apple provides as the OS Framework. So now you've introduced this concern -- is the library available, or does the app need to carry it's own? Assuming someone takes the effort to get it right, not only does this nessecary duplication hurt diskspace (inconsequential), it also harms the purpose of dynamic loaded libraries: code shared in RAM. Each app now has to carry the full bloat burden of the libraries it calls into. For Gtk/GNOME and QT/KDE, this would likely be fatal as every program carries an entire copy of QT. By breaking out the libraries into their own packages, we can introduce versioning that alleviates "DLL hell" while avoiding the massive RAM demands of static builds. Not to mention it's basically impossible.
You could write a silly FUSE driver that presents something similar to Applications, limited to dragging INTO the directory(installing a package), copying an app (create a duplicate binary package), and deleting (uninstalling). But you wouldn't be able to run apps locally and expect the OS to be able to apply security updates.
Much in the same way folding chairs don't fit in at a haute cuisine restaurant, you have to pay attention to how the whole comes together. Maybe you should file a bug asking for the Human Theme to accept color controls. It's part of GNOME theming, but not supported by the current Human theme.
You know what they say: Behind every great man is a woman pushing him to excel. Or something. I'm just glad it worked out -- imagine the flame wars on what to rename the distro had they broken up!
Well, the book covers: * the history of Ubuntu * how the Ubuntu community is structured * how to contribute to Ubuntu * How to set up things far outside the ordinary usages "easy to use" would be intended to hit, like LTSP * and more!
Geebus H McChrystie. If you were any more arrogant, I'd rate you a troll. Class warfare? Different species? Perhaps, I'm a Homo Sapien and you've come off a Homo Knee-jerker.
Some fun facts:
I meant prestige of the manufacturer
I don't own and never have owned a 200 dollar video card, let alone a 500 dollar one
Even poor people wish to appear rich in America
My dad is a former Sprint business analyst / programmer
He now works as a stocker at Wal-Mart in the middle of Salina, KS
Fixed costs can be recovered wherever possible
A midrange card often outperforms even the best card from the previous generation
Hint: before you reply to a post with douchebaggery, I suggest asking a friend what they think of it first
Actually, my understanding is that the high end is primarily a prestige thing. You have the fastest GPU, people think "Well the best one's pretty expensive, but card $f00 a few notches down is reasonably priced" -- instead of comparing what you can afford to their competitors, you're comparing to their stuff. From a Profit x Volume standpoint, I imagine the 8600 is a how they "pay the R&D costs".
This seems to come as a surprise to many Linux advocates, but they just want their recently purchased device to work."> Really? Because when I go to the mall, I go shopping for things I know won't work. I ask the helpful clerks which stuff they've heard doesn't work, and then buy them! I can't imagine why any Linux enthusiast like myself would do otherwise.
Face it, you're full of shit -- the argument wasn't about getting stuff working or not, or about users understanding how their cars, computers and machinery work. It was about which way to make things work was best. Your derailing of the conversation by claiming that debate was somehow outlying actions for users to take has somewhat succeeded, but fortunately nothing productive is accomplished on the likes of Slashdot. But personally, if Joe Dipshit is the last to adopt Linux, I'm not sure what's wrong with that. In many ways GNU/Linux is a success -- it has found a way to attract and grow the things it needs to survive: developers.
No, it's that these people claim to have experience writing drivers in the kernel. This is a much smaller set of people than userspace. And while talented people who can dive into the kernel exist, it's a waste of human capital to direct kernel developers at something like that.
This sounds like exactly the sort of thing that Launchpad was written to handle far better than a wiki page. Launchpad has some support for linking bugs to upstream. It's not quite finished, as each upstream is possibly it's own special tracker, but you'd at least get a better picture of what's in progress, what has an upstream and when upstream isn't being very responsive.
Slashdot Mirror
People buy computers to do things for them. Not so they can do things to computers. As more computing power becomes available, we should expect that software comes out of the box capable of doing more things with that power. These are great features for creating presentations, writing letters, looking for an old paper you wrote, and surfing the web, all of which already runs smoothly on most every ancient computer out there. I dare say that better UIs and cheaper cameras are making photo processing into the same den, and the system can also handle that fine and well.
Where Microsoft has really failed is at successfully offering distinctive versions. Its clear enough it was driven more by naive marketing than good product design. Home, Home premium, Business, Ultimate? The fact that many people have to read what's being offered in each and compare means they've already failed. They're treated as cubby holes with which to put in features and capture those who'd pay 400 for an operating system. It would have been wiser to offer Home, Business and Gamer. Gamers are the ones who're pissed about performance and obsess over free RAM and idle disk. They'll discount things like shadow volume copies, backup policies, or search indexing. They'll even disable GL window effects if it means degraded performance. So turn that shit off by default, give them an insightfully tuned computer out of the box, for what they want.
I can only imagine that Microsoft is trying to move the gamers off the PC and onto the 360, where they receive royalties for every game sold.
Actually, I think we do care about the rights to the recording, since their objection is that Harmonic's recording of their song sounds too much like theirs, even though they apparently paid for the rights to make a new recording of it. I think the best we can really say about this mess is that making music records is like making sausage.
Indeed. The purpose of salting and hashing is that they protect the passwords from the administrative staff, and anyone else who can historically see the data.
What's far more scary is the number of sites that want your email address as a user login. Imagine how many people use the same password across sites, including their email account...
Invite? They revel in it! They make a habit of publishing silly rebuttals to legal threats, and apparently their country of origin supports them to a surprising degree.
Search indexers hit every file once, most programs hit the same file over and over. The former is bad for cache, the latter is great.
AFAIK, Linux has a unified buffer cache. Meaning VM pressure will push block data out, and FS pressure will push VM out. The secondary effect is to nuke the file cache, but the big complaint people had was programs getting pushed out due to indexers. In effect, the cache is cleaned of any relevance, being "filled" with filesystem junk thanks to the poor locality of indexers. So you wake up and the GNOME libs all have to come back in, etc.
Free ram *is* wasted RAM, after the first few percentage points to deal with immediate allocation needs. It costs you the same to power RAM whether it holds meaningful information or not. So it might as well cache SOMETHING.
Unused RAM is wasted RAM. Presumably file system cache is filling up the space freed by things now in swap. It's a balance between using RAM for RAM and using it for faster disk read / writes. If the machine goes unused for a time, there shouldn't be any pressure either way. Linux machines used to have a small problem with search indexers running nightly and busting the cache by hitting every directory and file on disk.
Seriously though, swap is not a performance critical system anymore. By this I mean, while the existence of swap can be beneficial to system performance, the things that go into swap today rarely come out -- swapping is not the expected use case anymore. Therefore you can be as slow as you like with it. So basically, you shouldn't be worried about fragmentation either way.
Placement on disk also cares about the frequency and size of swap requests. If your caching system just pushed a little too close to the working set, then you'll have small requests infrequently, and the time will be dominated by seek, not throughput. If you're mostly just storing the unused 2/3rds of a DLL or startup code for a few kilo/megabytes more of FS cache, placement is also irrelevant. Only when you expect to actually have a working set larger than memory will placement really start to matter. Try measuring the activity of the swapfile during various activities. If you've got a gig or two of RAM, it shouldn't move much.
Really, ther's no need to measure average seek times and disk access metrics in order to optimize swap, though they're still interesting experiments for obsessive geeks.
Of course, Switzerland also has more social programs, along with free education. Meaning people who might be otherwise unemployed aren't even looking right yet. And the definition of unemployment is the percent of people who want work but can't find any.
What is delicious?
No, it's like store brand shaving cream designed to mimic the branding of expensive shampoos, and placed nearby. In your example, there's at least a good chance you'll walk home with shampoo.
After the second time, who would insure them without positive proof of countermeasures? It almost has to be fraud.
Except these are security convoys. They're not rushing off to find a terrorist. They're running security patrols or escorting foreign civilian traffic. I don't recall having to yield for a semi carrying food in the states. The reason they have to go fast is because if they stop, they'll get their asses trapped, and subsequently kicked, for venturing outside the security perimeter.
The US Army is great at fighting other Geneva Convention signers. But those ethics also form a weakness. If you're the sort of person who wants victory at all costs, I guess Bush's erosion of torture and other former ethics are a boon. The whole purpose of the DARPA project is to reduce the casulties in the event of an attack on a convoy (and probably to set up diversions).
It's a lot of man hours to remove the LSB assumptions into the code base. Plus you'd have convince every upstream application that yours is the one true way, when they've already signed on. Ubuntu doesn't own the code they give to you, and they certainly don't command the people who did write the code. It'd be not only a lot of work now, but more work every release in the future to merge patches upstream refuses to accept. And it requires a lot of ugliness with shipping libraries (I'll cover that more in a moment) that have already been solved.
Moreover, it breaks security. Currently, every package within Ubuntu main is attended to by the security team. Even things as trivial as buffer overflows in a game's image handler will be addressed (in main). Simply discarding package management in favor of drag and dropping means discarding this universal security policy. So now every application has to duplicate update functionality, and do so securely.
It breaks efficiency. Firstly, you're effectively spreading libraries out on disk, meaning more seeks to navigate the directory structure, versus one for
You could write a silly FUSE driver that presents something similar to Applications, limited to dragging INTO the directory(installing a package), copying an app (create a duplicate binary package), and deleting (uninstalling). But you wouldn't be able to run apps locally and expect the OS to be able to apply security updates.
Much in the same way folding chairs don't fit in at a haute cuisine restaurant, you have to pay attention to how the whole comes together. Maybe you should file a bug asking for the Human Theme to accept color controls. It's part of GNOME theming, but not supported by the current Human theme.
Because the kernel did that. The old drivers are depricated. If you think this sucks, try telling of Linus Torvalds.
You know what they say: Behind every great man is a woman pushing him to excel. Or something. I'm just glad it worked out -- imagine the flame wars on what to rename the distro had they broken up!
Well, the book covers:
* the history of Ubuntu
* how the Ubuntu community is structured
* how to contribute to Ubuntu
* How to set up things far outside the ordinary usages "easy to use" would be intended to hit, like LTSP
* and more!
Some fun facts:
Actually, my understanding is that the high end is primarily a prestige thing. You have the fastest GPU, people think "Well the best one's pretty expensive, but card $f00 a few notches down is reasonably priced" -- instead of comparing what you can afford to their competitors, you're comparing to their stuff. From a Profit x Volume standpoint, I imagine the 8600 is a how they "pay the R&D costs".
Face it, you're full of shit -- the argument wasn't about getting stuff working or not, or about users understanding how their cars, computers and machinery work. It was about which way to make things work was best. Your derailing of the conversation by claiming that debate was somehow outlying actions for users to take has somewhat succeeded, but fortunately nothing productive is accomplished on the likes of Slashdot. But personally, if Joe Dipshit is the last to adopt Linux, I'm not sure what's wrong with that. In many ways GNU/Linux is a success -- it has found a way to attract and grow the things it needs to survive: developers.
No, it's that these people claim to have experience writing drivers in the kernel. This is a much smaller set of people than userspace. And while talented people who can dive into the kernel exist, it's a waste of human capital to direct kernel developers at something like that.
This sounds like exactly the sort of thing that Launchpad was written to handle far better than a wiki page. Launchpad has some support for linking bugs to upstream. It's not quite finished, as each upstream is possibly it's own special tracker, but you'd at least get a better picture of what's in progress, what has an upstream and when upstream isn't being very responsive.
I don't recall Stephen Colbert being a corporation, although he is a fictional person.