And by "some", I mean enough to address at least 10% of their claimed "shortfall". If they really want to convince me, 20%+ would do it.
School isn't cheap and not many people want to invest the time and money in a CS degree when they believe that the jobs will be outsourced before they've paid off their college loans.
So, get rid of the worry about the loan by offering scholarships. Lots of scholarships. Every year.
Some people prefer to work really late in "deep hack mode".
Others prefer 8-5 job and forget about the work when you leave.
It all depends upon your personality and the requirements of the job. And IF WHAT THE ARTICLE SAYS IS CORRECT finding a job more in line with your personality should be easy.
I've found library hell to be worse on Linux, even with Ubuntu, in my experience than in Windows.
Okay, but now explain HOW it is "worse".
Under Ubuntu, if the library isn't in the repository, that single app won't install so you know it won't work.
With Windows, installing a new app causes one or more existing (and previously working) apps to stop working.
As for (B) and stress tests, The trick isn't so much to put a high load in all the time, but to trigger the wrong event in the wrong state, stress tests can easily miss this one.
Which would indicate that it was a software bug if that behaviour was documented or known.
Such would be a hardware bug if such was not documented and behaved differently in different pieces... or if it was documented but not correctly implemented in any of those pieces. Either way, it should be very easy to troubleshoot. And with Linux, it is very easy to troubleshoot that.
Regarding the crashing though, I found that on my Windows system, most crashes can be attributed to either
(A) Bad hardware (B) Bad drivers - usually the graphics driver.
While that may be your experience, if such were the case with the majority, Windows would be far more reliable than it is.
That would be because it should be easy to identify the buggy drivers (your "B") or to use a diagnostic program to stress test the other components (your "A").
In my experience (supporting 100+ workstations), Windows is just arcane. Following the exact same install process with the exact same install CD's will give you different results on different machines (same make and model)... and if you do it often enough you'll get different results on the same machine.
Then we get into the whole concept of the Registry and DLL Hell and so forth. Un-installing an app may not get rid of all of the crap from that app and so you'll have stuff just sitting around waiting to trigger a crash. And different versions of DLL files overwrite each other so re-installing may fix app A, but break app B.
Troubleshooting on Linux is so much easier and faster. Which is one of the reasons I prefer Ubuntu (or vanilla Debian).
It would be a real slap in the face for Michael Dell if after all the support for linux installed computers was shown on the ideas website, and the company taking steps to do so, and then find out there isn't really a demand for them.
#1. The "support" has to include ALL the hardware on the box.
#2. The boxes have to be the most popular boxes Dell sells already.
#3. The price cannot be higher than the equivalent Windows box.
We've already seen "support" which doesn't include everything in the box, which only includes boxes that most people wouldn't buy in the first place and which, for some reason, cost MORE than buying the same box with Windows.
That's just a ploy to "show" that "no one" really wants Linux on the desktop. Fuck Dell. We've heard it before. If they're really serious this time, it's up to them to demonstrate that.
If the packets aren't being forged, then it's not difficult to identify them and block them at an upstream router.
As long as the ISP has decent routers and people capable of correctly configuring them.
And that allows one ISP to talk to the other ISP and provide them with a list of addresses and times so that those customers can be notified or other action taken.
The ISP knows the IP addresses on their network. There shouldn't be any reason for a forged packet to go out over their routers.
Right now, there is no reason why the ISP's cannot charge different rates for blocking/opening outbound connections on port 25. The average home user won't be running an SMTP server INTENTIONALLY and will happily take a $5 per month savings for having such blocked.
There, two of the worst problems on the Internet are significantly reduced. THEN we can start talking about whether ISP's aren't making enough profits.
And that is what "Net Neutrality" comes down to. The profits.
Once you start instituting "tiers" you take away ANY incentives to increase the available bandwidth.
Instead, the "innovation" will go towards extracting the most revenue from the smallest pipes. And "innovation" is in quotes because it won't be real innovation. It will be accounting tricks and tier pricing.
But the Reality is that most meetings suck, are mis-managed and a waste of time. Why these things are true does not matter. They are and they aren't going to change.
So, avoid meetings as much as possible. Use email and the telephone and finally, talk to people in their cubicles/offices. Use the one-to-one means of communicating as much as possible. People will give you more information and more SENSITIVE information in person than they will in a group.
Once you have all of that and you've run through the email/telephone/cubicle cycle a few times, then call a short meeting to make sure that everyone sees everyone else agreeing in public to what they've agreed to.
The people will still be the people. They might be voting against you, but they are still the people.
In a Democracy, the government will still be the government. You might not be re-elected to it, but it is still the government.
The politician is not the government. The politician is not the nation. The politician is not the people.
These have all existed before the politician and will exist after the politician.
But the politician will attempt to confuse them and portray himself/herself as the people, the nation, the government, the only thing that stands between all of them and oblivion.
I'm not sure why you're assuming that/.'ers will in general put overprotectionism over free speech. I'd guess the exact opposite.
Read the comments on the dupe.
Free speech is something that we shouldn't have a double standard about.
I agree with that. But there is also a tendency for people to look to "authority" for "protection" from "threats".
Even when that authority should NOT have any authority over the perceived "threat". Which is why I referenced the "bullying".
Once people start expecting/demanding that an "authority" provide them "protection", that authority will not willingly yield any of its newly found power.
Post a story about some teacher demanding that some kid take down his personal, non-school website calling the teacher a poopy-head and the/. comments will be against the teacher, citing "free speech".
Post a story about some teacher demanding that some kid take down his personal, non-school website calling some kid a poopy-head and the/. comments will be for the teacher, citing "I was bullied when I was a kid".
Either the school does control the lives of the kids outside of school or it does not.
The authority of the school should end where the school grounds end.
Why is data so unsecured that the receptionist who plugs in her iPod can somehow get access to identity/medical histories? That's not the fault of the iPod or the receptionist.
Because without physical security there is no security.
Locking down the PC so that the receptionist cannot move data to his/her iPod would also, logically, prevent the iPod from doing anything that s/he would want it to do.
Unless you configured an iPod specific rule. And security is broken by "exceptions".
Going with your lDAP example, just always install the LDAP libraries. What's the harm? A few kilobytes of disk space in exchange for a much-simplified package system is a perfectly acceptable tradeoff.
But there are some incredibly bright people working on Linux. You never know whether one of them can come up with a simple and elegant solution to a problem such as this without asking.
Such functionality would probably be beyond the basic options of installing an unpackaged app from source code. But there's no reason that additional information couldn't be included with packaged apps detailing the more common options.
The fewer apps you're running, the fewer avenues of attack there are for you to be compromised. This could be a great feature for securing boxes.
With apt, your #10 is as easy as putting a line in your/etc/apt/sources.list file. But there should be some way of identifying all the packages (and everything should be a package) on your system and where to find the updates for them.
Maybe even some way of running a report to find all the packages who's upgrade sites have not shown any activity in X days/months/years. And some means of pointing that package to a new site. Or even a way of identifying what packages were NOT checked for updates during a check.
Assuming that you can find the source code with a partial configuration file for the new requirements, the system should identify what functionality has been included and what has not been included and offer to try to guess what acceptable entries would be (or allow you to enter your own).
What pisses me off is the 32 step process to making a deb (that's what dpkg calls a package btw.. just incase you're playing acronym bingo out there). So if you want to install something you built from source, and be able to remove it later, you need some freakin' magician to have made it into a source package.. cause there's no way in hell you're doing it yourself.
Who has the longest or most distinguished genealogy doesn't matter. We all borrow from each other now, anyway.:)
Once the requirements can be hammered down... we can start looking at the MINIMUM lines of code that would have to be included with the source code to turn that source code into an application that can be installed and maintained (to some minimum degree) by the next generation of rpm or apt or dpkg or yum or whatever.
I believe that all these articles focus on the wrong issue. It isn't about which package manager is "best" or which method of installing software is "best". The "best" is different for each admin. What is "best" for someone managing 5,000 boxes at Google may not be the "best" for someone managing 100 boxes at some other company. Nor would either of those ways be "best" for someone running his/her own box at home. Nor would any of those ways be "best" for someone doing development work at IBM.
Instead, let's look at everything that could possibly be needed... and then make it easiest for the most commonly encountered issues.
If one of the issues is getting unpackaged code onto your machines, what is the minimum information needed, in what format, which can be handled (safely) by the main package management systems?
And that is... define the requirements that the next generation package manager should have.
That way there is no need to worry about "replacing" the existing systems. You can instead focus on evolving them to meet the requirements. Even if each distribution/project takes its own path to get there.
#1. It must make installing new software as easy as it currently is with apt.
#2. The same for upgrading the software.
#3. The same for removing the software.
#4. The same for handling dependencies. Including the order in which dependencies must be installed.
#5. The same for validating the installed software against the original software (checksums or whatever).
#6. The same for re-installing the software over the existing installation when you accidentally delete or over-write something.
#7. The ability to point the updater at your own repository or multiple repositories.
#8. The ability to recompile (automatically) any software that you install for your specific hardware.
Anything else? Yeah, I know most of this is already handled with apt. But that's what I'm most familiar with. I keep seeing all the articles about "problems" but I don't seem to run into any problems on my server or workstations (and I'm running Feisty Fawn on my workstation).
Slashdot Mirror
And by "some", I mean enough to address at least 10% of their claimed "shortfall". If they really want to convince me, 20%+ would do it.
School isn't cheap and not many people want to invest the time and money in a CS degree when they believe that the jobs will be outsourced before they've paid off their college loans.
So, get rid of the worry about the loan by offering scholarships. Lots of scholarships. Every year.
So you had seen in back with 9x
Here's an article from 2005
http://msdn.microsoft.com/msdnmag/issues/05/04/Re
Some people prefer to work really late in "deep hack mode".
Others prefer 8-5 job and forget about the work when you leave.
It all depends upon your personality and the requirements of the job. And IF WHAT THE ARTICLE SAYS IS CORRECT finding a job more in line with your personality should be easy.
If what the article says is correct.
Okay, but now explain HOW it is "worse".
Under Ubuntu, if the library isn't in the repository, that single app won't install so you know it won't work.
With Windows, installing a new app causes one or more existing (and previously working) apps to stop working.
Which would indicate that it was a software bug if that behaviour was documented or known.
Such would be a hardware bug if such was not documented and behaved differently in different pieces
While that may be your experience, if such were the case with the majority, Windows would be far more reliable than it is.
That would be because it should be easy to identify the buggy drivers (your "B") or to use a diagnostic program to stress test the other components (your "A").
In my experience (supporting 100+ workstations), Windows is just arcane. Following the exact same install process with the exact same install CD's will give you different results on different machines (same make and model)
Then we get into the whole concept of the Registry and DLL Hell and so forth. Un-installing an app may not get rid of all of the crap from that app and so you'll have stuff just sitting around waiting to trigger a crash. And different versions of DLL files overwrite each other so re-installing may fix app A, but break app B.
Troubleshooting on Linux is so much easier and faster. Which is one of the reasons I prefer Ubuntu (or vanilla Debian).
#1. The "support" has to include ALL the hardware on the box.
#2. The boxes have to be the most popular boxes Dell sells already.
#3. The price cannot be higher than the equivalent Windows box.
We've already seen "support" which doesn't include everything in the box, which only includes boxes that most people wouldn't buy in the first place and which, for some reason, cost MORE than buying the same box with Windows.
That's just a ploy to "show" that "no one" really wants Linux on the desktop. Fuck Dell. We've heard it before. If they're really serious this time, it's up to them to demonstrate that.
As long as "Linux" has the drivers for the hardware. That's all that matters.
If the packets aren't being forged, then it's not difficult to identify them and block them at an upstream router.
As long as the ISP has decent routers and people capable of correctly configuring them.
And that allows one ISP to talk to the other ISP and provide them with a list of addresses and times so that those customers can be notified or other action taken.
Not only spam but also the DDoS attacks.
The ISP knows the IP addresses on their network. There shouldn't be any reason for a forged packet to go out over their routers.
Right now, there is no reason why the ISP's cannot charge different rates for blocking/opening outbound connections on port 25. The average home user won't be running an SMTP server INTENTIONALLY and will happily take a $5 per month savings for having such blocked.
There, two of the worst problems on the Internet are significantly reduced. THEN we can start talking about whether ISP's aren't making enough profits.
And that is what "Net Neutrality" comes down to. The profits.
"Net Neutrality" is the way to go.
Once you start instituting "tiers" you take away ANY incentives to increase the available bandwidth.
Instead, the "innovation" will go towards extracting the most revenue from the smallest pipes. And "innovation" is in quotes because it won't be real innovation. It will be accounting tricks and tier pricing.
But the Reality is that most meetings suck, are mis-managed and a waste of time. Why these things are true does not matter. They are and they aren't going to change.
So, avoid meetings as much as possible. Use email and the telephone and finally, talk to people in their cubicles/offices. Use the one-to-one means of communicating as much as possible. People will give you more information and more SENSITIVE information in person than they will in a group.
Once you have all of that and you've run through the email/telephone/cubicle cycle a few times, then call a short meeting to make sure that everyone sees everyone else agreeing in public to what they've agreed to.
Meetings suck. Avoid them.
The people will still be the people. They might be voting against you, but they are still the people.
In a Democracy, the government will still be the government. You might not be re-elected to it, but it is still the government.
The politician is not the government. The politician is not the nation. The politician is not the people.
These have all existed before the politician and will exist after the politician.
But the politician will attempt to confuse them and portray himself/herself as the people, the nation, the government, the only thing that stands between all of them and oblivion.
Most of the time the politicians WANT the people to be afraid because fear is an emotion and emotions are easier to use when re-election time comes.
Politicians who run on fear don't have any thing else.
Download the stuff off-campus and then send it to your on-campus site over a secured connection.
Firewall that site so only on-campus addresses can access it. If you want to, make it invitation only. Just remember to encrypt the transmissions.
There, now no one off-campus can tell that you're doing anything at all on-campus.
Read the comments on the dupe.
I agree with that. But there is also a tendency for people to look to "authority" for "protection" from "threats".
Even when that authority should NOT have any authority over the perceived "threat". Which is why I referenced the "bullying".
Once people start expecting/demanding that an "authority" provide them "protection", that authority will not willingly yield any of its newly found power.
Post a story about some teacher demanding that some kid take down his personal, non-school website calling the teacher a poopy-head and the /. comments will be against the teacher, citing "free speech".
/. comments will be for the teacher, citing "I was bullied when I was a kid".
Post a story about some teacher demanding that some kid take down his personal, non-school website calling some kid a poopy-head and the
Either the school does control the lives of the kids outside of school or it does not.
The authority of the school should end where the school grounds end.
Because without physical security there is no security.
Locking down the PC so that the receptionist cannot move data to his/her iPod would also, logically, prevent the iPod from doing anything that s/he would want it to do.
Unless you configured an iPod specific rule. And security is broken by "exceptions".
EXACTLY!
Instead of working out a BETTER SYSTEM, they just pushed the fiscal responsibility for the FLAWED SYSTEM to the merchants.
The merchants are the ones LEAST ABLE to fix the existing system or implement a better system or validate that the transaction is legit.
The ONLY people that this is good for is Visa/Mastercard. They make huge profits without the risk.
But there are some incredibly bright people working on Linux. You never know whether one of them can come up with a simple and elegant solution to a problem such as this without asking.
Such functionality would probably be beyond the basic options of installing an unpackaged app from source code. But there's no reason that additional information couldn't be included with packaged apps detailing the more common options.
The fewer apps you're running, the fewer avenues of attack there are for you to be compromised. This could be a great feature for securing boxes.
With apt, your #10 is as easy as putting a line in your /etc/apt/sources.list file. But there should be some way of identifying all the packages (and everything should be a package) on your system and where to find the updates for them.
Maybe even some way of running a report to find all the packages who's upgrade sites have not shown any activity in X days/months/years. And some means of pointing that package to a new site. Or even a way of identifying what packages were NOT checked for updates during a check.
Thanks!
Assuming that you can find the source code with a partial configuration file for the new requirements, the system should identify what functionality has been included and what has not been included and offer to try to guess what acceptable entries would be (or allow you to enter your own).
Checkinstall http://www.debian-administration.org/articles/147
It's not the answer to all issues regarding installing from source
Any suggestions on what would make them even better?
Who has the longest or most distinguished genealogy doesn't matter. We all borrow from each other now, anyway. :)
... we can start looking at the MINIMUM lines of code that would have to be included with the source code to turn that source code into an application that can be installed and maintained (to some minimum degree) by the next generation of rpm or apt or dpkg or yum or whatever.
... and then make it easiest for the most commonly encountered issues.
Once the requirements can be hammered down
I believe that all these articles focus on the wrong issue. It isn't about which package manager is "best" or which method of installing software is "best". The "best" is different for each admin. What is "best" for someone managing 5,000 boxes at Google may not be the "best" for someone managing 100 boxes at some other company. Nor would either of those ways be "best" for someone running his/her own box at home. Nor would any of those ways be "best" for someone doing development work at IBM.
Instead, let's look at everything that could possibly be needed
If one of the issues is getting unpackaged code onto your machines, what is the minimum information needed, in what format, which can be handled (safely) by the main package management systems?
#9. Good point. Being able to easily roll-back an "upgrade" that didn't work would be a very nice feature. So I've marked this as number nine.
...
In fact, Ubuntu might be switching to the Smart Package Manager http://labix.org/smart/faq which seems to support this functionality.
I also left out
#10. Mark packages so that they will NOT be upgraded. The same as I can do with apt.
And that is ... define the requirements that the next generation package manager should have.
That way there is no need to worry about "replacing" the existing systems. You can instead focus on evolving them to meet the requirements. Even if each distribution/project takes its own path to get there.
#1. It must make installing new software as easy as it currently is with apt.
#2. The same for upgrading the software.
#3. The same for removing the software.
#4. The same for handling dependencies. Including the order in which dependencies must be installed.
#5. The same for validating the installed software against the original software (checksums or whatever).
#6. The same for re-installing the software over the existing installation when you accidentally delete or over-write something.
#7. The ability to point the updater at your own repository or multiple repositories.
#8. The ability to recompile (automatically) any software that you install for your specific hardware.
Anything else? Yeah, I know most of this is already handled with apt. But that's what I'm most familiar with. I keep seeing all the articles about "problems" but I don't seem to run into any problems on my server or workstations (and I'm running Feisty Fawn on my workstation).