I wonder how much the IRS figures into its revenue stream the profit obtained via people filing taxes and not knowing what they're doing. Folks who use professional preparation services no doubt get them correct most of the time and owe the correct amount (or get the right refund), but how many people are just doing it via paper and submitting, and, due to the arcane, maze of rules and regulations, overpay and don't claim the exemptions they should?
Leave it up to the IRS -- they probably have it figured out that if they pre-fill items on forms, that means less error and less money. Plus, this gives them more opportunity to audit and assess fees. Whee!
A good suggestion; I have an iPhone and do keep a few things in there. The problem is that the information I take down is only for my convenience and it is infinitely easier to glance over to a notepad or sticky note on my desk as I'm typing or on the phone than it is to spend the half-minute it'll take to pull the correct note up on my phone. That being said, you're right for things more long-term and needing to be mobile, and I do use the phone for those, including taking lots of pictures of wiring, servers, etc. It's the combination of tools that makes everything run smoothly.
I'm going to dissent from the typical opinion here and say that I'd love this, even in its current form. In my duties as a programmer and sysadmin, I'm constantly jotting down things on sticky notes that I need to remember for one, two, maybe 5 days and then never again. A user's password so I can set up an account, a table schema so I can refer to it easily, a network diagram until I get it put into Visio, an IP, a telephone number, an IMEI, any number of things. I am always and forever using a sticky note and then trashing it. This would simply allow me to replace them with something functionally the same but without waste.
Yes, I agree -- it would be awesome to have the ability to save and have multiple pages. But let's not overlook what good it has already, which I'd say is quite a lot.
While I certainly agree with a lot of your philosophies (protecting your network, avoiding having to clean up the mess, etc.) as I work in IT myself and am on the sysadmin AND helpdesk side (we're a jack-of-all sort of department), besides obvious issues like viruses, spyware, and the like, it comes down to two main philosophies: Is managing your users' time on the network an IT issue or an HR issue?
At our site, it's split but definitely in favor of HR. If there is someone abusing the bandwidth and clearly doing things other than their work, we'll notice and often we get requests from HR to investigate a particular user here or there. It's easy enough to handle. But most of the time we don't bother and we really don't care if people take a few minutes during their day to catch up on FB, read the latest scores, check the weather, etc. We figure it's no different than allowing them some watercooler time, a bathroom break, or a chat in the hallway. We want everyone to feel that we trust them to do what they've been hired to do and if they're not -- well, that's an issue for HR to work out with them, not IT.
Perhaps your site is less trustworthy and you get far more abuse of work time than we do, but I would estimate that out of 200+ employees we probably have a 0.25% abuse rate, if that. Coupled with a far, far more simple IT infrastructure that doesn't require hardly any of my time to manage and I think our solution is working very nicely by simply assuming that most people we hire are going to do their jobs and we only need a few things in place to catch the ones who insist on not doing so.
YMMV, naturally.
You miss my point. The point is that an appropriate level of documentation is always correct, but at some level, the system should explain itself to some degree. No programmer worth their salt goes through and writes comments like, "This is a function. The function "get_an_integer" gets an integer." That's inane, because any programmer taking over should be able to look at the system and figure it out, because there are industry/practice-standard ways of writing and doing things that are meant to make such knowledge transferable.
Hence with documenting the network -- some of it should simply explain itself. Yes, if there's specific, custom ways it is configured, it should be documented, but those custom configs should be few and far between to keep the need for documentation low. I only say all this because the way the OP phrased his question made it sound like the entire contraption was this Rube Goldberg machine of networking components that would require some complex PhD to understand, and that sounds like a problem with implementation, not with documentation.
Am I the only one who first thought, "If you have done the network correctly, it should explain itself"?
Overly-complex networks take overly-complex documentation and overly-complex people to run and maintain. Mind you, there's a difference between correctly-complex and incorrectly-complex, but at the same time, every level of difficulty you go upwards in the configuration scale you exponentially increase the need for carefully calculated and layed-out systems.
Ok, ok...now that I'm thrust back into reality...and given that you aren't likely to rebuild your network (although you might consider some re-work to help the self-explanatory aspect)...
High level details, locations of closets, routers, switches, major cable runs, passwords, IPs, big details. All the small things the other person will have to figure out anyway and catalogue in their own mind in their own way, so doing it for them won't help a ton. Give them the tools to do their job properly and you'll be sitting fine.
I imagine so.:) And I've done without a sewer for 48 hours once because ours backed up. It sucked like no other suck.
Yes, of course I'm joking, because RMS takes everything to the extreme and beyond the intention instead of lodging a legitimate concern. Fact is, some things I care about if I can patch the system or modify the code, and some things -- I don't. I really don't give a rat's ass about some things because I just really want to get work or life done and out of the way.
Hence, sewers. By letting the city dictate my sewage handling prices, how my house hooks up to it, and what I'm allowed to put into it, I'm giving up control but, really? I don't want control of that, and I'm happy enough not to have to handle it.
"'Sewer as a service' means that you think of a particular sewer as doing your poop disposal for you. If that's what the sewer does, you must not use it! If you do your pooping on someone else's sewer, you hand over control of your poop to whoever controls the sewer. It is like using truck-stop toilet paper, only worse: it's even harder for you to wipe an ass that's sitting on someone else's toilet than it is to wipe an ass sitting on your own bog. Just like dye-free Charmin, 'sewer as a service' is incompatible with your bowel freedom."
When I was in college, I completely had a crush on this terribly cute Russian exchange MIS student (much more business-savvy than CS savvy) who always needed help with her programming courses. Unfortunately, due to the different body language characteristics, I never could interpret whether she thought I was more than just a tutor or not, so I never made that leap. She was terribly delicious, however. Alas.
Ahem. Computer labs -- needed!:)
Most of IT, good IT, has been rendered boring by the application of structure and formalization to it. Back in the day, IT folks were seat-of-the-pants, contriving solutions on the fly, hacking live systems, being the hero in the closet that saved the day. Once IT became supremely important to the enterprise, it got controlled, structured, and rules came out. Standards and methodologies started controlling everything from server deployment to code writing. The job went from keyboard slinging console cowboys to geeks in a meeting room constructing project plans.
This is not to say that the IT that is performed these days isn't GOOD -- it is, far, far better than much of the code and product produced in the halcyon days of the industry. But it lacks the excitement, uncertainty, and massive heroics of yesteryear. This, more than anything, is what has rendered IT "boring" to most grads.
The excitement comes now from doing a job well, from taking the requirements and still coming up with the creative answers within the frameworks defined, and saving the day by knowing that niche information at the critical time. But gone are the days of a geek-in-a-corner, whacking out miracles and clobbering something together out of voodoo magic to the saviour of all.
It beats out a mythbox because the first two points are more important than the third. If it doesn't work reliably most of the time without fiddling and my wife can't run it without swearing, it's no good. Myth is a great product, don't get me wrong, but it requires some know-how to get up, running, and good hardware to be stable and productive. The interface tends to be a bit more cryptic, too. It takes me all of an hour, max, to get another Tivo dropped into my network and online and set up, and my wife can use it immediately. The hackability factor only comes along after those primary requirements.
I don't dislike your ideas -- I'd be happy with a "lite" version for those of us who just want a really good email client and nothing else. Or rather, keep all the enhancements that make it a good enterprise application to modules and extensions, not the core. Hell, for all I care, make a core that is simply an engine for handling messages of any type -- want email? Install the email extension. Newsgroups? Newsgroup extension. Be nice to pick and choose my functionality without being forced to swallow the entire pill because someone *else* decided it'd be the best medicine for me.
TiVo has some great things going for it. Whether or not it can beat the marketing and packaging deals of the cable and sat companies, I don't know, but there's some aspects that just beat out other offerings, including Mythboxen:
It works. All the time, every time, with minor exceptions. I have a wife who loves certain TV programs and will easily strangle anything that doesn't work and record them like they should.
It doesn't require a degree to run Sure, it might lack some more complex features that some people like. It might make annoying, "to-TOINK!", noises when you move around. But an idiot with a blindfold could sort it out, and that makes it easy on me. Not that my wife's an idiot; far from it. But I don't need to be explaining to her how to run the damned TV.
I can screw with it Because I own the box, it's mine. I can hack it, fiddle with it, change out hard drives, use them for something else, add to it, paint it, whatever I want. I might void my warranty, but whoop-de-do. I can because I own it.
I, for one, am not looking forward to the idea of having Tbird as a community project, unless it is headed by a small team of very focused individuals. A mass free-for-all will simply destroy it due to feature bloat and a multitude of ideas around what an email client should be.
What should an email client do? How about -- email. Just email. Not email and newsgroups, not email and collaboration, not email and Facebook -- just plain old simple email. Sure, I'll concede to HTML email for you folks who can't stand to not have a little color in your lives and insist on spamming my box with your yellow backgrounds and pink text, but it's still email.
Tbird is awesome and makes almost no waves because of a) marketing -- the browser wars are much more publicized, b) marketing -- Microsoft isn't really trying to take over the world with Outlook, because they know it sucks, and c) marketing -- There's not much word-of-mouth going on because email mostly works with just about any client and people put up with it, so there's not as much of a scramble for a "good" email client.
I love the app. It works and works and works and doesn't break and doesn't screw up one of the most important things in my online life, electronic mail. I don't want to see it backburnered by the Foundation, either, but at the same time, I'm happier thinking that the Foundation has their finger on where it's going and so far, I trust that they're not going to make it suck. So I'd be preferable to leaving it their hands for that reason.
It's very similar to income taxes, really. If I am employed by a company (under a W-2), they take out taxes for me. If I'm self-employed, I have to pay my own taxes and they do NOT get automatically taken. If I fail to pay taxes on my income, however, I'm still liable for them, because everyone has to pay them, no matter how you earn your money.
This guy is just self-employed in terms of fuel choice, but that doesn't remove him from the obligation to pay tax on it. He can claim ignorance till he's blue in the face, but the IRS doesn't take that excuse for income so its unlikely anyone else is going to take it for the fuel tax.
I think there's perhaps 2 considerations that have prompted the "more LEDs" and "brighter LEDs" movement in newer technology:
#1. Gamers and other such folk who trick out their boxes with windows, interior lights, glow-in-the-dark strips, etc. These have prompted more and flashier lights and so forth. "Ooooh...blue lights. It must have PWR!"
#1. When providing technical support, if there's a dull-green LED lighting up the power switch and you have Aunt Josie looking at a box tucked in a corner in a room that's so lit up that the light of God himself is shamed, if that LED isn't burning at 1.5mil candlepower, she won't be able to tell if it's on or not. "Well, I think...uh....yes? Maybe. Maybe yes. That's what I think." *headdesk*
However, I agree with the original article insomuch as more options need to be had for dimming, shuttering, etc. I don't think you'll ever get anyone to actually follow it, however.
Why not make something that, when the story gets to the point of "sliding off", if the article has recevied a certain threshold of commentary, it'll stay on the page in preference to articles above it (newer) that are below the comment threshold. IE:
Story 1: 350 comments
Story 2: 100 comments
Story 3: 400 comments
Threshold: 300 comments
Story 3 gets about ready to slide off the page, but since Story 2 is below the threshold, it slides off first, leaving Story 3 to linger a bit longer. But when Story 2 comes down far enough, it is above the threshold, so Story 3 slides off.
I think that slashdot is stylistically more akin to a mailing list or blog than to the NYT or WSJ. We are informal. Which is what I want Slashdot to be. Casual. To hire a copy editor and purge all these things from Slashdot changes the tone of the site.
Fair enough -- I can understand that argument. You're quite right when you say that "professionally" formatted news sites project a certain tone, much like "professional" news channels use a "professional" accent and formatting. I can understand, from your perspective, why you do not want this to change.
That being said -- I often wonder if it is an inevitable progression of Slashdot to advance to a more formal news site, despite the desires of its founders. The massive exposure and influence in the world is clearly evident, whether being quoted in major publications or taking out major websites from the sheer momentum of the community. Many eyes -- many important eyes -- fall upon these hallowed, green-trimmed pages each day. Professionals in the IT industry and others regularly use, "I saw it on Slashdot", as a reputable source for their current knowledge on a subject. I know I often do so myself.
With such a weight of responsibility thrust upon this medium to present not only the content of the article in a good light but the entire site in a favorable way, I look for Slashdot to move more towards professionalism rather than away from it. Does it change the tone? Yes. Will it move beyond the designs and intentions of the founders? Most likely. Sites that boom often progress far beyond their original visions.
I think this is the crux of the matter that grammar/spelling freaks tend to harp upon -- the site has already moved beyond "downtown pub" because now instead of 15 well-known people coming to drink beer every night, you now have the entire population of Manhattan showing up to have cocktails and weenies. The site has evolved and progressed despite your wishes to the contrary, and now the community wants to see the editing and attitude progress as well. Whether or not this is a desireable progression or not is, I think, beyond the scope of the reality of the situation.
Fair enough, and I will fully admit that I am *not* qualified to comment on whether a stable ABI is possible or not. I simply do not know all the technical details behind it. My *impression* is that it's not an impossible thing to do, but most kernel hackers don't even consider the technical aspects of it because their idealisms get in the way.
I have now read (yeah, yeah, read before replying -- bite me) this article about why a stable kernel interface is a bad idea. Some very, very good points here that, in essence, I have trouble debating from a technical standpoint. Ok, tough to keep things up-to-date, developers don't want to have to keep the old interfaces in place because it makes a maintenance nightmare, and you possibly sacrifice the stability of the OS as a whole if you do.
Well, that's groovy. I can dig that in ways that shovels can't even begin to contemplate.
The thing that always strikes me, though, is this: The kernel is developed on the F/OSS idealistic system, yet it is striving to break into the mainstream. However, the mainstream simply doesn't work that way. In the Real World(tm), you have to have backwards compatibility, you have to have systems that don't break APIs and standards very often, and you have to have an ease of development for anyone and everyone who wants to contribute to it. Why? Because this is how business works. Business doesn't always have time to stop and, "Do it the right way." Companies can't employ kernel hackers to work 24/7 on keeping a single driver up-to-date because the kernel changes all the time. It's like having a coworker that continually changes the function parameters of the code I'm trying to interface with -- I'd fucking kill him! I don't have time for that shit, and I suspect that's the attitude of many corporations who would otherwise contribute to Linux.
Same old, same old, folks. Idealisms meet reality, big mess ensues. I hate sitting on the fence between the two, but I see good points on both sides. Resolving the conflicts, however, isn't always cut-and-dried.
One thing I don't get about this is why a stable kernel driver API wouldn't benefit BOTH GROUPS -- the ones who want to release binary-only drivers and the ones who want to write open-source drivers. Both could use the API to interface with the kernel. Having a stable API means that open-source writers wouldn't have to continuously rewrite their code to be compatible with each release of the kernel. I'll be that'd make a LOT of people happy.
This doesn't mean the API can never change -- it just can't change with every revision. Change it at the big mileposts -- 2.4, 2.6, 2.8, etc.
"But it violates our idealisms!" shriek the F/OSS pundits. Well, that's a nice, happy, kum-bah-ya image you have going in your head there, Family Circle, but it's not reality. Some companies are going to be willing to create open-source drivers, some won't. Some protect their code with all power. So what? No skin off your back just because they won't open it. It doesn't violate your ideals just because someone HAS written a closed-source driver that works with your operating system. Don't use it! Write your own! I invite you. What would it hurt to have both a binary and an open driver for each piece of hardware?
Having an attitude of, "We'll make it so you CAN'T use binary drivers and then they'll open up their source!" is ignorant. You might get one or two converts to that ideal, but most are going to give you the bird and go their own way. Meanwhile you're alienating tons people that would otherwise use your software AND contribute to it, but they can't get their $150 video card to work and so have given up. The power of F/OSS is in numbers and you can't afford to not have them.
Remember: Another ideal of many F/OSS advocates is that just because you can use something in a negative way doesn't mean the idea is bad. DRM? Not a bad idea. Can be used in bad ways, though. TPM? Same idea. Even Linus said it. Kernel driver API? Could be used in many different ways, some good, some bad, some desireable, some less so. Doesn't mean the idea is bad. Quit throwing the baby out with the bathwater simply because there's a good chance that The Man will take advantage of it.
Slashdot Mirror
I wonder how much the IRS figures into its revenue stream the profit obtained via people filing taxes and not knowing what they're doing. Folks who use professional preparation services no doubt get them correct most of the time and owe the correct amount (or get the right refund), but how many people are just doing it via paper and submitting, and, due to the arcane, maze of rules and regulations, overpay and don't claim the exemptions they should?
Leave it up to the IRS -- they probably have it figured out that if they pre-fill items on forms, that means less error and less money. Plus, this gives them more opportunity to audit and assess fees. Whee!
A good suggestion; I have an iPhone and do keep a few things in there. The problem is that the information I take down is only for my convenience and it is infinitely easier to glance over to a notepad or sticky note on my desk as I'm typing or on the phone than it is to spend the half-minute it'll take to pull the correct note up on my phone. That being said, you're right for things more long-term and needing to be mobile, and I do use the phone for those, including taking lots of pictures of wiring, servers, etc. It's the combination of tools that makes everything run smoothly.
I'm going to dissent from the typical opinion here and say that I'd love this, even in its current form. In my duties as a programmer and sysadmin, I'm constantly jotting down things on sticky notes that I need to remember for one, two, maybe 5 days and then never again. A user's password so I can set up an account, a table schema so I can refer to it easily, a network diagram until I get it put into Visio, an IP, a telephone number, an IMEI, any number of things. I am always and forever using a sticky note and then trashing it. This would simply allow me to replace them with something functionally the same but without waste.
Yes, I agree -- it would be awesome to have the ability to save and have multiple pages. But let's not overlook what good it has already, which I'd say is quite a lot.
While I certainly agree with a lot of your philosophies (protecting your network, avoiding having to clean up the mess, etc.) as I work in IT myself and am on the sysadmin AND helpdesk side (we're a jack-of-all sort of department), besides obvious issues like viruses, spyware, and the like, it comes down to two main philosophies: Is managing your users' time on the network an IT issue or an HR issue? At our site, it's split but definitely in favor of HR. If there is someone abusing the bandwidth and clearly doing things other than their work, we'll notice and often we get requests from HR to investigate a particular user here or there. It's easy enough to handle. But most of the time we don't bother and we really don't care if people take a few minutes during their day to catch up on FB, read the latest scores, check the weather, etc. We figure it's no different than allowing them some watercooler time, a bathroom break, or a chat in the hallway. We want everyone to feel that we trust them to do what they've been hired to do and if they're not -- well, that's an issue for HR to work out with them, not IT. Perhaps your site is less trustworthy and you get far more abuse of work time than we do, but I would estimate that out of 200+ employees we probably have a 0.25% abuse rate, if that. Coupled with a far, far more simple IT infrastructure that doesn't require hardly any of my time to manage and I think our solution is working very nicely by simply assuming that most people we hire are going to do their jobs and we only need a few things in place to catch the ones who insist on not doing so. YMMV, naturally.
You miss my point. The point is that an appropriate level of documentation is always correct, but at some level, the system should explain itself to some degree. No programmer worth their salt goes through and writes comments like, "This is a function. The function "get_an_integer" gets an integer." That's inane, because any programmer taking over should be able to look at the system and figure it out, because there are industry/practice-standard ways of writing and doing things that are meant to make such knowledge transferable.
Hence with documenting the network -- some of it should simply explain itself. Yes, if there's specific, custom ways it is configured, it should be documented, but those custom configs should be few and far between to keep the need for documentation low. I only say all this because the way the OP phrased his question made it sound like the entire contraption was this Rube Goldberg machine of networking components that would require some complex PhD to understand, and that sounds like a problem with implementation, not with documentation.
Am I the only one who first thought, "If you have done the network correctly, it should explain itself"? Overly-complex networks take overly-complex documentation and overly-complex people to run and maintain. Mind you, there's a difference between correctly-complex and incorrectly-complex, but at the same time, every level of difficulty you go upwards in the configuration scale you exponentially increase the need for carefully calculated and layed-out systems. Ok, ok...now that I'm thrust back into reality...and given that you aren't likely to rebuild your network (although you might consider some re-work to help the self-explanatory aspect)... High level details, locations of closets, routers, switches, major cable runs, passwords, IPs, big details. All the small things the other person will have to figure out anyway and catalogue in their own mind in their own way, so doing it for them won't help a ton. Give them the tools to do their job properly and you'll be sitting fine.
I imagine so. :) And I've done without a sewer for 48 hours once because ours backed up. It sucked like no other suck.
Yes, of course I'm joking, because RMS takes everything to the extreme and beyond the intention instead of lodging a legitimate concern. Fact is, some things I care about if I can patch the system or modify the code, and some things -- I don't. I really don't give a rat's ass about some things because I just really want to get work or life done and out of the way.
Hence, sewers. By letting the city dictate my sewage handling prices, how my house hooks up to it, and what I'm allowed to put into it, I'm giving up control but, really? I don't want control of that, and I'm happy enough not to have to handle it.
"'Sewer as a service' means that you think of a particular sewer as doing your poop disposal for you. If that's what the sewer does, you must not use it! If you do your pooping on someone else's sewer, you hand over control of your poop to whoever controls the sewer. It is like using truck-stop toilet paper, only worse: it's even harder for you to wipe an ass that's sitting on someone else's toilet than it is to wipe an ass sitting on your own bog. Just like dye-free Charmin, 'sewer as a service' is incompatible with your bowel freedom."
When I was in college, I completely had a crush on this terribly cute Russian exchange MIS student (much more business-savvy than CS savvy) who always needed help with her programming courses. Unfortunately, due to the different body language characteristics, I never could interpret whether she thought I was more than just a tutor or not, so I never made that leap. She was terribly delicious, however. Alas. Ahem. Computer labs -- needed! :)
Most of IT, good IT, has been rendered boring by the application of structure and formalization to it. Back in the day, IT folks were seat-of-the-pants, contriving solutions on the fly, hacking live systems, being the hero in the closet that saved the day. Once IT became supremely important to the enterprise, it got controlled, structured, and rules came out. Standards and methodologies started controlling everything from server deployment to code writing. The job went from keyboard slinging console cowboys to geeks in a meeting room constructing project plans.
This is not to say that the IT that is performed these days isn't GOOD -- it is, far, far better than much of the code and product produced in the halcyon days of the industry. But it lacks the excitement, uncertainty, and massive heroics of yesteryear. This, more than anything, is what has rendered IT "boring" to most grads.
The excitement comes now from doing a job well, from taking the requirements and still coming up with the creative answers within the frameworks defined, and saving the day by knowing that niche information at the critical time. But gone are the days of a geek-in-a-corner, whacking out miracles and clobbering something together out of voodoo magic to the saviour of all.
It beats out a mythbox because the first two points are more important than the third. If it doesn't work reliably most of the time without fiddling and my wife can't run it without swearing, it's no good. Myth is a great product, don't get me wrong, but it requires some know-how to get up, running, and good hardware to be stable and productive. The interface tends to be a bit more cryptic, too. It takes me all of an hour, max, to get another Tivo dropped into my network and online and set up, and my wife can use it immediately. The hackability factor only comes along after those primary requirements.
I don't dislike your ideas -- I'd be happy with a "lite" version for those of us who just want a really good email client and nothing else. Or rather, keep all the enhancements that make it a good enterprise application to modules and extensions, not the core. Hell, for all I care, make a core that is simply an engine for handling messages of any type -- want email? Install the email extension. Newsgroups? Newsgroup extension. Be nice to pick and choose my functionality without being forced to swallow the entire pill because someone *else* decided it'd be the best medicine for me.
That explains all those uncomfortable moments when I feel another foot touching mine in bed and my wife is in the bathroom...
Sadly, I can't argue against this. But for now, I can dream, right? Right? Bueller?
It works. All the time, every time, with minor exceptions. I have a wife who loves certain TV programs and will easily strangle anything that doesn't work and record them like they should.
It doesn't require a degree to run Sure, it might lack some more complex features that some people like. It might make annoying, "to-TOINK!", noises when you move around. But an idiot with a blindfold could sort it out, and that makes it easy on me. Not that my wife's an idiot; far from it. But I don't need to be explaining to her how to run the damned TV.
I can screw with it Because I own the box, it's mine. I can hack it, fiddle with it, change out hard drives, use them for something else, add to it, paint it, whatever I want. I might void my warranty, but whoop-de-do. I can because I own it.
I, for one, am not looking forward to the idea of having Tbird as a community project, unless it is headed by a small team of very focused individuals. A mass free-for-all will simply destroy it due to feature bloat and a multitude of ideas around what an email client should be.
What should an email client do? How about -- email. Just email. Not email and newsgroups, not email and collaboration, not email and Facebook -- just plain old simple email. Sure, I'll concede to HTML email for you folks who can't stand to not have a little color in your lives and insist on spamming my box with your yellow backgrounds and pink text, but it's still email.
Tbird is awesome and makes almost no waves because of a) marketing -- the browser wars are much more publicized, b) marketing -- Microsoft isn't really trying to take over the world with Outlook, because they know it sucks, and c) marketing -- There's not much word-of-mouth going on because email mostly works with just about any client and people put up with it, so there's not as much of a scramble for a "good" email client.
I love the app. It works and works and works and doesn't break and doesn't screw up one of the most important things in my online life, electronic mail. I don't want to see it backburnered by the Foundation, either, but at the same time, I'm happier thinking that the Foundation has their finger on where it's going and so far, I trust that they're not going to make it suck. So I'd be preferable to leaving it their hands for that reason.
It's very similar to income taxes, really. If I am employed by a company (under a W-2), they take out taxes for me. If I'm self-employed, I have to pay my own taxes and they do NOT get automatically taken. If I fail to pay taxes on my income, however, I'm still liable for them, because everyone has to pay them, no matter how you earn your money.
This guy is just self-employed in terms of fuel choice, but that doesn't remove him from the obligation to pay tax on it. He can claim ignorance till he's blue in the face, but the IRS doesn't take that excuse for income so its unlikely anyone else is going to take it for the fuel tax.
I think there's perhaps 2 considerations that have prompted the "more LEDs" and "brighter LEDs" movement in newer technology:
#1. Gamers and other such folk who trick out their boxes with windows, interior lights, glow-in-the-dark strips, etc. These have prompted more and flashier lights and so forth. "Ooooh...blue lights. It must have PWR!"
#1. When providing technical support, if there's a dull-green LED lighting up the power switch and you have Aunt Josie looking at a box tucked in a corner in a room that's so lit up that the light of God himself is shamed, if that LED isn't burning at 1.5mil candlepower, she won't be able to tell if it's on or not. "Well, I think...uh....yes? Maybe. Maybe yes. That's what I think." *headdesk*
However, I agree with the original article insomuch as more options need to be had for dimming, shuttering, etc. I don't think you'll ever get anyone to actually follow it, however.
Are you there, God? It's me, Hermione.
Oops. I meant when Story 1 comes down far enough, it'll force Story 3 to slide off. Damned fingers. :P~
RE: sliding off the page
Why not make something that, when the story gets to the point of "sliding off", if the article has recevied a certain threshold of commentary, it'll stay on the page in preference to articles above it (newer) that are below the comment threshold. IE:
Story 1: 350 comments
Story 2: 100 comments
Story 3: 400 comments
Threshold: 300 comments
Story 3 gets about ready to slide off the page, but since Story 2 is below the threshold, it slides off first, leaving Story 3 to linger a bit longer. But when Story 2 comes down far enough, it is above the threshold, so Story 3 slides off.
I think that slashdot is stylistically more akin to a mailing list or blog than to the NYT or WSJ. We are informal. Which is what I want Slashdot to be. Casual. To hire a copy editor and purge all these things from Slashdot changes the tone of the site.
Fair enough -- I can understand that argument. You're quite right when you say that "professionally" formatted news sites project a certain tone, much like "professional" news channels use a "professional" accent and formatting. I can understand, from your perspective, why you do not want this to change.
That being said -- I often wonder if it is an inevitable progression of Slashdot to advance to a more formal news site, despite the desires of its founders. The massive exposure and influence in the world is clearly evident, whether being quoted in major publications or taking out major websites from the sheer momentum of the community. Many eyes -- many important eyes -- fall upon these hallowed, green-trimmed pages each day. Professionals in the IT industry and others regularly use, "I saw it on Slashdot", as a reputable source for their current knowledge on a subject. I know I often do so myself.
With such a weight of responsibility thrust upon this medium to present not only the content of the article in a good light but the entire site in a favorable way, I look for Slashdot to move more towards professionalism rather than away from it. Does it change the tone? Yes. Will it move beyond the designs and intentions of the founders? Most likely. Sites that boom often progress far beyond their original visions.
I think this is the crux of the matter that grammar/spelling freaks tend to harp upon -- the site has already moved beyond "downtown pub" because now instead of 15 well-known people coming to drink beer every night, you now have the entire population of Manhattan showing up to have cocktails and weenies. The site has evolved and progressed despite your wishes to the contrary, and now the community wants to see the editing and attitude progress as well. Whether or not this is a desireable progression or not is, I think, beyond the scope of the reality of the situation.
Fair enough, and I will fully admit that I am *not* qualified to comment on whether a stable ABI is possible or not. I simply do not know all the technical details behind it. My *impression* is that it's not an impossible thing to do, but most kernel hackers don't even consider the technical aspects of it because their idealisms get in the way.
A small addendum to my above comment:
I have now read (yeah, yeah, read before replying -- bite me) this article about why a stable kernel interface is a bad idea. Some very, very good points here that, in essence, I have trouble debating from a technical standpoint. Ok, tough to keep things up-to-date, developers don't want to have to keep the old interfaces in place because it makes a maintenance nightmare, and you possibly sacrifice the stability of the OS as a whole if you do.
Well, that's groovy. I can dig that in ways that shovels can't even begin to contemplate.
The thing that always strikes me, though, is this: The kernel is developed on the F/OSS idealistic system, yet it is striving to break into the mainstream. However, the mainstream simply doesn't work that way. In the Real World(tm), you have to have backwards compatibility, you have to have systems that don't break APIs and standards very often, and you have to have an ease of development for anyone and everyone who wants to contribute to it. Why? Because this is how business works. Business doesn't always have time to stop and, "Do it the right way." Companies can't employ kernel hackers to work 24/7 on keeping a single driver up-to-date because the kernel changes all the time. It's like having a coworker that continually changes the function parameters of the code I'm trying to interface with -- I'd fucking kill him! I don't have time for that shit, and I suspect that's the attitude of many corporations who would otherwise contribute to Linux.
Same old, same old, folks. Idealisms meet reality, big mess ensues. I hate sitting on the fence between the two, but I see good points on both sides. Resolving the conflicts, however, isn't always cut-and-dried.
One thing I don't get about this is why a stable kernel driver API wouldn't benefit BOTH GROUPS -- the ones who want to release binary-only drivers and the ones who want to write open-source drivers. Both could use the API to interface with the kernel. Having a stable API means that open-source writers wouldn't have to continuously rewrite their code to be compatible with each release of the kernel. I'll be that'd make a LOT of people happy.
This doesn't mean the API can never change -- it just can't change with every revision. Change it at the big mileposts -- 2.4, 2.6, 2.8, etc.
"But it violates our idealisms!" shriek the F/OSS pundits. Well, that's a nice, happy, kum-bah-ya image you have going in your head there, Family Circle, but it's not reality. Some companies are going to be willing to create open-source drivers, some won't. Some protect their code with all power. So what? No skin off your back just because they won't open it. It doesn't violate your ideals just because someone HAS written a closed-source driver that works with your operating system. Don't use it! Write your own! I invite you. What would it hurt to have both a binary and an open driver for each piece of hardware?
Having an attitude of, "We'll make it so you CAN'T use binary drivers and then they'll open up their source!" is ignorant. You might get one or two converts to that ideal, but most are going to give you the bird and go their own way. Meanwhile you're alienating tons people that would otherwise use your software AND contribute to it, but they can't get their $150 video card to work and so have given up. The power of F/OSS is in numbers and you can't afford to not have them.
Remember: Another ideal of many F/OSS advocates is that just because you can use something in a negative way doesn't mean the idea is bad. DRM? Not a bad idea. Can be used in bad ways, though. TPM? Same idea. Even Linus said it. Kernel driver API? Could be used in many different ways, some good, some bad, some desireable, some less so. Doesn't mean the idea is bad. Quit throwing the baby out with the bathwater simply because there's a good chance that The Man will take advantage of it.