"[...] they want as much feedback as they can get on the beta."
Translation: Microsoft can't decide what it should do, and doesn't want to spend the money figuring it out, so they'd rather get the tech-savvy people who'd be willing to try out a beta to tell them how it should behave.
Memory [RAM] (and its difference between the hard drive)
CPU
Monitor
Keyboard
Network interface
Removable storage
CD-ROM device (it's not a cupholder!)
Understanding what the filesystem is, and how it works:
Files are not stored in applications, they are stored in files
("I forgot where on the filesystem I saved my file," instead of
"I saved a file in Word, and now it's not in Word anymore.")
Understanding copying, moving, and deleting files.
Understanding that opening an existing file, changing it, and using "Save As..."
doesn't modify the original file.
Computers are not magic:
Configuration can't always be automatic; sometimes you have to configure things yourself.
If your computer behaves differently than before, it probably means that something has changed.
Your computer is doing more than what the visible windows show (e.g. background processes).
Error messages and confirmation dialogs have important text in them, and shouldn't always be dismissed:
If a website unexpectedly asks you to install a program, don't install it!
Sometimes, error messages give you the information you need to fix a problem (e.g. insert a floppy disk).
You are capable of solving many of your own problems:
Google is your friend.
The man pages (or help files) are your friend.
The program's output (dialog boxes, status bar, e.g.) is your friend.
It means more sales in the short-term, but it also means sales lost in the long-term due to customer dissatisfaction. Closed drivers do suck, and they hamper the idea of open-source software. Open code means that bugs can, and will, get fixed quicker. Often (with good leadership), it also means that bugs get good quality fixes, instead of market-driven hacks. Vendors have very little to lose by open-sourcing their drivers. The source already exists. They might as well open up the source and let people with better motivation than "just paying the bills" get into it and fix it. It amazes me how short-sighted hardware manufacturers are when they choose to keep their drivers closed-source. Why pay software developers to develop closed-source solutions when the OSS community would, often, gladly accept the responsibility, and even provide you a better-quality driver for a fraction of the money that you'd spend developing the closed-source equivalent?
Now, hand in your/. ID card on your way out for failing to support OSS when appropriate;)
You're closer to right, but still wrong. Strong typing and type safety both relate to the same property of a language. Ruby and Python are dynamically-typed languages, where C/C++ and Java are statically-typed. Static vs. dynamic typing lie on a different axis than strong/weak typing.
Asked if any company can become the 'Microsoft of Linux', Greg responds "Well, if we ever woke up one day and said 'Wow, Novell is the Microsoft of Linux' or 'Red Hat is the Microsoft of Linux', then the Linux movement would be over." Is he right -- is the open source world free from such possibilities?
Linux is only a subset of what open source has to offer. There's much more to open-source than Linux. A pedantic note, maybe, but I'm tired of the "open source = linux" thinking that pervades the business realm and even leaks over into the IT realm.
Agreed, maybe it was too strong. (Love the sig, BTW). However, the underlying concept remains. The microkernel is still more architecturally sound than a macrokernel, even if it has obvious performance issues. You can optimize out performance issues. It is much, MUCH harder to retrofit wise architectural decisions than optimizations.
Sigh. That's what firewalls are for. Spyware is rendered useless if your firewall says, "Umm, no, you can't connect to the Internet. Aren't you a filesystem utility anyway? How naughty! No Internet for you!"
Umm, doesn't that mean while you've prooved that the 10k microkernel lines correct, you'd still have ~6 million lines of code sitting outside the microkernal waiting to be prooved? I can't see how a microkernel can magically do with 10k everything Linux is doing with 6 million lines (especially as by the definition of microkernel, than there's no way it could).
If the majority of the system services are implemented by one "server" or "module" with ~6m LOC, then you're missing the point of a microkernel anyway. In a properly-implemented microkernel system, those 6m LOC would be split into well-defined, easily-provable chunks. As the LOC increases, it becomes exponentially harder to prove the code's correctness. As an example, let's consider the "index of provability" to be 2^LOC (an exponential expression). So, proving a 6m LOC kernel would be: 2^6e6 (a number requiring six million binary digits to express)
Now, let's consider breaking that 6m LOC kernel into 20k chunks. Each chunk would be 2^20k, and there would be 300 chunks. So, the index of provability for the microkernel would be:
300 * 2^2e4 = 2^2.0002e4 * 3 * 5^2 (a number requiring 2.0009e4 binary digits to express)
The latter is MUCH smaller. Breaking the system down into smaller chunks helps provability a LOT.
When people go and by a new computer, many are willing to spend hundreds of dollars more to get a little extra performance. They will not like to have that taking away from them just so that they can run a microkernel.
Agreed, but these are the same people who don't really care if they're at the bleeding edge of technology and have to deal with super-l33t video driver 0.8.2b crashing every so often.
It is just a false premise, just because some monolithic (or hybrid) kernels are unreliable does not mean that it is necessary or better to use microkernels to get reliability.
I'm afraid the false assumption has fallen upon you here. It's proven, time and again, that microkernels make it simpler to guarantee security and reliability. Yes, microkernels hurt performance a bit. However, it's throwing the baby out with the bathwater to discard microkernel architecture because of performance. By discarding microkernel architecture, you also discard the architectural segregation of system services, which makes for a very simple way to segragate effort when you've got say, an open-source project with developers located around the globe. Microkernels also ease maintenance, again, because the kernel remains small.
A HUGE misstep that the monolithic kernel camp has made by pointing fingers at microkernels' performance is this: smart coders write good, clean, testable, reliable, secure programs first, and optimize later. One should never, EVER attempt to optimize code on the first pass. Write it, test it, fix it, THEN optimize it. Leave the clearly non-optimal code in during the first few passes, just for the sake of maintenance. Then, you'll have a good, clean codebase from which to begin profiling and optimizing.
I can personally testify to spending exorbitant amounts of time debugging architecturally un-sound code, written intentionally so, because a wise architectural decision would've resulted in lesser performance. Out of curiosity, I usually run profilers over this code. Most often, these architectural decisions result in such a negligible performance increase that it pales in comparison to the maintenance nightmare that ensues from it.
There's nothing magical about microkernels that prevents them from being optimized, just like any other program. The benefits of the microkernel architecture certainly outweigh the performance hit in my book.
I recommend sodium chloride (5mg) if you disagree with any of the above.
I will concede that FreeBSD, in terms of implementing the latest bells and whistles, is behind Linux. Often, it's far behind linux. However, the strength of FreeBSD (and most of the BSDs) is not in how many of the latest features get crammed into the next release, it's the stability and correctness of how the operating system works. Furthermore, the FreeBSD developers and maintainers have worked very hard to create a sane way of getting things done. I love the fact that any operator-installed packages are never going to clash with the base system install./usr/local/* is the appropriate place for non-base-system stuff to go, no matter what. I love the fact that threads are truly lightweight processes. I love the fact that the kernel, boot process, and base system install are all, together, what makes FreeBSD. You get no such guarantees from Linux. As so many people around here are in the habit of pointing out, Linux is just a kernel. Keeping the kernel tied with the appropriate binaries and scripts is what helps keep FreeBSD stable.
I wanted to migrate from Windows on my desktop to Linux, and I found linux, especially with the built-in package management features of a few distros, to be almost impossible to administer and still remain current. It took me days, DAYS, to get a linux distro up-and-running to be sufficiently ready to use as a desktop. It took me < 2 hours for FreeBSD. FreeBSD has remained stable, secure, and easy-to-use ever since. Heck, I can even run software built for Linux on my FreeBSD system through its robust Linux compatibility layer. Look at Netcraft's longest-uptime charts, and see how many of the top entries are BSD systems. You say FreeBSD is dying -- I say FreeBSD is growing.
Now, go on, eat up. The above is 100% Purina Troll Chow. Keep on trolling if you're still hungry.
You forgot: ruins small businesses -- family country stores ran by generations suddenly without a prayer to compete.
To expound a bit, this is often done by the corporation subsidizing local price cuts until those local businesses have either gone under or stopped attempting to compete on price. Therefore, Wal-Mart is bringing in more money to its own stores in the local markets based on this subsidization, but failing to return much of that money back to the local economy. As soon as a Wal-Mart store becomes well-established, it then becomes part of the money machine that provides the subsidization for the next local market that is being subdued by the Wal-Mart corporation. Economies of scale* is only one part of how Wal-Mart ruins local business.
The end result is that much of the commerce in a town is going to a corporation that has little concern for the health of the local economy. Mom-and-pop business management types are much more likely to be concerned with having a thriving local economy, since they are also consumers in the same market. There's no such thing as "product pride" at Wal-Mart; there are countless stories of Wal-Mart desiring to do business providing "good enough" products en masse, rather than providing good products. Therefore, local economies are flooded with throw-away products, from lawnmowers to kitchen appliances, and our entire culture becomes inundated with the idea that all products should be as cheaply-made, easily-broken, and inexpensively purchased as what Wal-Mart sells. Therefore, Mom and Pop, who take pride in the products they sell, go out of business. Sure, Mom and Pop are selling more expensive stuff, but, more often than not, that extra price is a reflection of the quality.
* One could argue that the Wal-Mart stores themselves are the products of an Economy of scale; I made this footnote to avoid the potential for an ugly battle of semantics.
I have also participated in the ACM programming contest (only got to regional competition, but it was fun). I had the unusual experience of having a programming-related job while I was still in college, and I can certainly confirm the parent's description of ACM programming contests being far from real-world earning-an-income coding. It's clear when you realize that an 8 to 5 desk job is much different than you remember from the contests in college, but it's really clear when you've already got a programming job and you go to an ACM programming contest.
The really successful coders are the ones that can learn new APIs and languages over a weekend. They're the ones who can communicate with non-technical people. They're the ones who can write a design for an application that will take a team of twelve developers a year to implement. The ACM programming contest compares to real-life CS work in the same way that a lumberjack competition proves a person's suitability for work in the logging industry. In both cases, the two sets of skills (contest vs. real life) overlap very little.
Slashdot Mirror
I think this classic bit is very much appropriate here. Managers hear what they want to hear.
Perhaps "Failing Unit Tests Fixed" would be a better metric.
But I'm sure it'll all come full-circle with Web 3.14159 =)
(-1, bad pun)
... when Gordon Freeman finally gets his tea? Hasn't he been wandering around with "no tea" for long enough?
"[...] they want as much feedback as they can get on the beta."
Translation: Microsoft can't decide what it should do, and doesn't want to spend the money figuring it out, so they'd rather get the tech-savvy people who'd be willing to try out a beta to tell them how it should behave.
Yes, apparently Office products are tons more feature-rich than their open-source equivalents....
He's this guy, the inventor of PGP.
It means more sales in the short-term, but it also means sales lost in the long-term due to customer dissatisfaction. Closed drivers do suck, and they hamper the idea of open-source software. Open code means that bugs can, and will, get fixed quicker. Often (with good leadership), it also means that bugs get good quality fixes, instead of market-driven hacks. Vendors have very little to lose by open-sourcing their drivers. The source already exists. They might as well open up the source and let people with better motivation than "just paying the bills" get into it and fix it. It amazes me how short-sighted hardware manufacturers are when they choose to keep their drivers closed-source. Why pay software developers to develop closed-source solutions when the OSS community would, often, gladly accept the responsibility, and even provide you a better-quality driver for a fraction of the money that you'd spend developing the closed-source equivalent?
/. ID card on your way out for failing to support OSS when appropriate ;)
Now, hand in your
I'm not a grammar nazi, but my friend Bob is.
With modules, you don't get a warm fuzzy feeling inside, telling you that microkernels are truly superior.
Along with the fringe benefit of knowing that those proprietary drivers can't crash your kernel.
You're closer to right, but still wrong. Strong typing and type safety both relate to the same property of a language. Ruby and Python are dynamically-typed languages, where C/C++ and Java are statically-typed. Static vs. dynamic typing lie on a different axis than strong/weak typing.
It's a wooden stick with the words "Not enough" imprinted on it.
prevents the 'promotion of a dispirited or negative view of life'.
Yeah, they'll give the breakers of this rule a healthy dose of soma.
Asked if any company can become the 'Microsoft of Linux', Greg responds "Well, if we ever woke up one day and said 'Wow, Novell is the Microsoft of Linux' or 'Red Hat is the Microsoft of Linux', then the Linux movement would be over." Is he right -- is the open source world free from such possibilities?
Linux is only a subset of what open source has to offer. There's much more to open-source than Linux. A pedantic note, maybe, but I'm tired of the "open source = linux" thinking that pervades the business realm and even leaks over into the IT realm.
Agreed, maybe it was too strong. (Love the sig, BTW). However, the underlying concept remains. The microkernel is still more architecturally sound than a macrokernel, even if it has obvious performance issues. You can optimize out performance issues. It is much, MUCH harder to retrofit wise architectural decisions than optimizations.
Sigh. That's what firewalls are for. Spyware is rendered useless if your firewall says, "Umm, no, you can't connect to the Internet. Aren't you a filesystem utility anyway? How naughty! No Internet for you!"
Umm, doesn't that mean while you've prooved that the 10k microkernel lines correct, you'd still have ~6 million lines of code sitting outside the microkernal waiting to be prooved? I can't see how a microkernel can magically do with 10k everything Linux is doing with 6 million lines (especially as by the definition of microkernel, than there's no way it could).
If the majority of the system services are implemented by one "server" or "module" with ~6m LOC, then you're missing the point of a microkernel anyway. In a properly-implemented microkernel system, those 6m LOC would be split into well-defined, easily-provable chunks. As the LOC increases, it becomes exponentially harder to prove the code's correctness. As an example, let's consider the "index of provability" to be 2^LOC (an exponential expression). So, proving a 6m LOC kernel would be:
2^6e6 (a number requiring six million binary digits to express)
Now, let's consider breaking that 6m LOC kernel into 20k chunks. Each chunk would be 2^20k, and there would be 300 chunks. So, the index of provability for the microkernel would be:
300 * 2^2e4 = 2^2.0002e4 * 3 * 5^2 (a number requiring 2.0009e4 binary digits to express)
The latter is MUCH smaller. Breaking the system down into smaller chunks helps provability a LOT.
When people go and by a new computer, many are willing to spend hundreds of dollars more to get a little extra performance. They will not like to have that taking away from them just so that they can run a microkernel.
Agreed, but these are the same people who don't really care if they're at the bleeding edge of technology and have to deal with super-l33t video driver 0.8.2b crashing every so often.
It is just a false premise, just because some monolithic (or hybrid) kernels are unreliable does not mean that it is necessary or better to use microkernels to get reliability.
I'm afraid the false assumption has fallen upon you here. It's proven, time and again, that microkernels make it simpler to guarantee security and reliability. Yes, microkernels hurt performance a bit. However, it's throwing the baby out with the bathwater to discard microkernel architecture because of performance. By discarding microkernel architecture, you also discard the architectural segregation of system services, which makes for a very simple way to segragate effort when you've got say, an open-source project with developers located around the globe. Microkernels also ease maintenance, again, because the kernel remains small.
A HUGE misstep that the monolithic kernel camp has made by pointing fingers at microkernels' performance is this: smart coders write good, clean, testable, reliable, secure programs first, and optimize later. One should never, EVER attempt to optimize code on the first pass. Write it, test it, fix it, THEN optimize it. Leave the clearly non-optimal code in during the first few passes, just for the sake of maintenance. Then, you'll have a good, clean codebase from which to begin profiling and optimizing.
I can personally testify to spending exorbitant amounts of time debugging architecturally un-sound code, written intentionally so, because a wise architectural decision would've resulted in lesser performance. Out of curiosity, I usually run profilers over this code. Most often, these architectural decisions result in such a negligible performance increase that it pales in comparison to the maintenance nightmare that ensues from it.
There's nothing magical about microkernels that prevents them from being optimized, just like any other program. The benefits of the microkernel architecture certainly outweigh the performance hit in my book.
I recommend sodium chloride (5mg) if you disagree with any of the above.
I think it's
{{{:-[
Sorry, couldn't resist.
I will concede that FreeBSD, in terms of implementing the latest bells and whistles, is behind Linux. Often, it's far behind linux. However, the strength of FreeBSD (and most of the BSDs) is not in how many of the latest features get crammed into the next release, it's the stability and correctness of how the operating system works. Furthermore, the FreeBSD developers and maintainers have worked very hard to create a sane way of getting things done. I love the fact that any operator-installed packages are never going to clash with the base system install. /usr/local/* is the appropriate place for non-base-system stuff to go, no matter what. I love the fact that threads are truly lightweight processes. I love the fact that the kernel, boot process, and base system install are all, together, what makes FreeBSD. You get no such guarantees from Linux. As so many people around here are in the habit of pointing out, Linux is just a kernel. Keeping the kernel tied with the appropriate binaries and scripts is what helps keep FreeBSD stable.
I wanted to migrate from Windows on my desktop to Linux, and I found linux, especially with the built-in package management features of a few distros, to be almost impossible to administer and still remain current. It took me days, DAYS, to get a linux distro up-and-running to be sufficiently ready to use as a desktop. It took me < 2 hours for FreeBSD. FreeBSD has remained stable, secure, and easy-to-use ever since. Heck, I can even run software built for Linux on my FreeBSD system through its robust Linux compatibility layer. Look at Netcraft's longest-uptime charts, and see how many of the top entries are BSD systems. You say FreeBSD is dying -- I say FreeBSD is growing.
Now, go on, eat up. The above is 100% Purina Troll Chow. Keep on trolling if you're still hungry.
Well if you use Gentoo already then you're a prime candidate for using BSD, because like BSD, Gentoo is following BSD down the path to oblivion.
Oblivion, you say? Your opinion comes from a trustworthy source, I'm sure....
Intel CoreTwin 2 Duo Pair, Mark Two!
You forgot: ruins small businesses -- family country stores ran by generations suddenly without a prayer to compete.
To expound a bit, this is often done by the corporation subsidizing local price cuts until those local businesses have either gone under or stopped attempting to compete on price. Therefore, Wal-Mart is bringing in more money to its own stores in the local markets based on this subsidization, but failing to return much of that money back to the local economy. As soon as a Wal-Mart store becomes well-established, it then becomes part of the money machine that provides the subsidization for the next local market that is being subdued by the Wal-Mart corporation. Economies of scale* is only one part of how Wal-Mart ruins local business.
The end result is that much of the commerce in a town is going to a corporation that has little concern for the health of the local economy. Mom-and-pop business management types are much more likely to be concerned with having a thriving local economy, since they are also consumers in the same market. There's no such thing as "product pride" at Wal-Mart; there are countless stories of Wal-Mart desiring to do business providing "good enough" products en masse, rather than providing good products. Therefore, local economies are flooded with throw-away products, from lawnmowers to kitchen appliances, and our entire culture becomes inundated with the idea that all products should be as cheaply-made, easily-broken, and inexpensively purchased as what Wal-Mart sells. Therefore, Mom and Pop, who take pride in the products they sell, go out of business. Sure, Mom and Pop are selling more expensive stuff, but, more often than not, that extra price is a reflection of the quality.
* One could argue that the Wal-Mart stores themselves are the products of an Economy of scale; I made this footnote to avoid the potential for an ugly battle of semantics.
Hear, hear!
I have also participated in the ACM programming contest (only got to regional competition, but it was fun). I had the unusual experience of having a programming-related job while I was still in college, and I can certainly confirm the parent's description of ACM programming contests being far from real-world earning-an-income coding. It's clear when you realize that an 8 to 5 desk job is much different than you remember from the contests in college, but it's really clear when you've already got a programming job and you go to an ACM programming contest.
The really successful coders are the ones that can learn new APIs and languages over a weekend. They're the ones who can communicate with non-technical people. They're the ones who can write a design for an application that will take a team of twelve developers a year to implement. The ACM programming contest compares to real-life CS work in the same way that a lumberjack competition proves a person's suitability for work in the logging industry. In both cases, the two sets of skills (contest vs. real life) overlap very little.