Cool. I'm in the same situation (cable for the computer, not for the TV) and I always thought it was just a harmless annoyance having MediaOne call up every couple of months for a customer survey about service I don't have. It looks like the problems could be more serious.
Fortunately (?) I'm moving outside of MediaOne's service area soon, so I'll just hope I make it until then without being indicted.;-)
Ahh, the old myth that "everyone's needs are [or should be] like mine".
A good network connection is sufficient if you can delete something when you need the space and then get it again off the net. This implies that _someone_ stored it. Now, if all you're doing is downloading content (including programs) generated by someone else, that's probably true, but who's going to store the content _you_ create, and on what are they going to store it? Mere users and creators who are content to freeload off someone else's storage can use the approach you espouse, but it doesn't work otherwise.
There are other reasons your approach is not universal. Transferring files is an example. Sure, if the connections at both ends and everything in between are all fast, maybe it'll work. But what if you have to work at a different site and they don't allow outside network connections (either physically or via firewall restrictions)? What if you want to leave your home machine powered off but still take your data to work? What if you want to give the files _you created_ to someone who doesn't have such a fast connection? What if you'd rather pay _one time_ for the drive and henceforth pay less for media than the monthly charge for the fast net connection? Or are you freeloading there too?
Lastly, a lesson from Tannenbaum: "never underestimate the bandwidth of a station wagon full of tapes". My employer has multiple OC-12 and better connections to the net (we dabble in 24/7 e-commerce hosting) and I _still_ never see network transfer rates comparable to disk transfer rates.
I don't think this is accurate. I've heard such claims for an actual _cut_ CD such as what your software comes on, but not for CD-R. AFAIK, the most stable medium writable by something you can put inside your desktop machine is MO.
Everyone knows that "lines of code" in the sense of the output from "wc -l" is totally useless as a measure of anything. That's just a strawman. Most "lines of code" measures at least take some account of braces and comments (though there's debate about whether it's fair to exclude comments) and some even take account of statement complexity to yield a _somewhat_ useful measure of productivity. But even finding fault with that is little better than attacking a strawman, because anyone with an ounce of sense knows that _any_ measure based solely on the code itself is likely to be inaccurate.
Any idiot can write 20K lines of code a year. It gets harder if you're only counting _properly debugged_ lines of code. It gets harder if you have to design whatever it is you're coding, and document the design, and have code reviewed, etc. It gets harder when what you're writing is intrinsically hard, such as a compiler or OS instead of GUI eye-candy. If the standards for non-coding activities are not held constant, the coding numbers are meaningless, and you can never really compare different types of code. I've worked with some people regarded as superstars within the industry, and very few of them can sustain a coding rate of even 50 lines of well-written, well-debugged, designed-from-scratch and reviewed kernel code per day. That's only 12.5K lines per year, but worth far more than 25K lines of derivative user-level crap any day.
Now the irony part. From the article: >One alternative is to tap reusable software components and object technologies to improve software development productivity
Think about it. Reusable code does improve _real_ productivity but by definition does not contribute to one's LOC numbers. It would be entirely reasonable to suppose that part of the reasons for US programmers' low numbers might be precisely because they _do_ take advantage of code reuse. Padding LOC numbers by writing a new version of something that already existed, because you didn't know any better, is a failing typical of very junior software engineers; more experienced hands know better.
For the authors of this article to criticize US programmers' "lack of productivity" using LOC, and then suggest code reuse as a solution, only shows their own ignorance.
College works for some people. Self-teaching works for some people. The one thing that's pretty much guaranteed is that someone who has both a college education _and_ real-world experience is more likely to be competent than someone who only has one or the other. Employers would rather go for the almost-sure bet than for either alternative where _maybe_ it will work out but the odds are worse, and employers certainly don't have any inclination to check out the specific circumstances of each and every individual candidate. Looking for both is an heuristic ("rule of thumb" for those who didn't go to college) that works pretty well overall.
I'd also like to make a point about those people who say "lack of a degree never held me back". First off, you would have learned in a statistics class that anecdotal evidence isn't generalizable. Secondly, one of the lessons you might have learned by studying either evolutionary biology or graph theory has to do with local optima and dead ends. Maybe your lack of a degree hasn't held you back..._yet_. Maybe you think you're climbing that mountain just fine, until you realize that your chosen approach brings you to an insurmountable cliff wall and your only choice will be to backtrack. I've seen people who've had to backtrack career-wise because they had thought they could skip learning some technique or technology. It's not pretty, and they didn't enjoy it much.
College may lead you in some pretty useless directions sometimes, but that 30000-foot view may come in handy when you can't see the terrain from the ground.
>Most of my friends do SysAdmin and Tech Support - and they usually know a lot more than the developers and consultants I have to work with.
I hear this claim a lot, and it's almost never true. What you probably mean is that they know less about _what you think it's important to know_ (e.g. system administration or tech support) _for your job_. My mother still asks me about Word macros and ICQ, because she knows I'm in computers and lacks the knowledge to distinguish a GUI/VB slob from a UNIX kernel hacker. Likewise, I'd say that very few sysadmins would be able to distinguish a great developer from a mediocre one even if they both slapped him (or her) in the face. You have your specialty, we have ours, and it's generally fair to judge each other by the same standards we'd use for those in our own field.
>I hope someday you realize the futility of silence, Jeff.
Oh, I know the futility of silence. What makes you assume I'm silent about issues that need to be addressed? This particular instance is a poor example of how I deal with such cases, since the only "wrong" thing D.H.Brown has done is provoke the knee-jerk reactions of a bunch of lightweights. When I care, I act.
My intent, beyond a little light-hearted fun, was to point out that if you want to be heard you'll have to do something better than identify yourself as a "Systems Designer" at some company nobody ever heard of. Why should they not assume that TekConnect is just another "vanity company" that only really exists at the local registrar's office? Why should they do anything but laugh at your threat never to buy any of their research when the probability was practically nil anyway? Don't explain the answers to me; explain to them.
Lacking anything more convincing than a made-up job title, it's hard to see your post as being truly aimed at getting results from D.H.Brown. Seems a lot more like dressing up in corporate-big-shot drag for the benefit of the kiddies here who don't realize how easy it is to fake these sorts of things.
>Congratulations! You have just assured that my company will never purchase any of your so-called "research". > >Systems Designer >TekConnect Corporation
I'm sure that scared them.
Jeff Darcy Founder, Systems Designer, and Chief Bottlewasher SuperWhizBangTek.com
>You can't get highly-available failover clusters with Linux. [though the linux-HA project is working on it]
Progress on this has been glacially so. That may be because the primary author was scared off when I, as one of the authors of the commercial product he was blatantly and transparently ripping off (he makes his living as a support engineer for that product, and had taken classes I had taught), sent him some email a while ago.
Or maybe it's because HA is a hard problem, and there seems to be a much greater interest in the Linux community in dicking around with themes and other brain candy than in solving hard problems.
>Alternatively, one could write a ufs/ffs for Linx
UFS/FFS is not a journaling filesystem, and does not solve the problems that journaling was invented to solve (primarily that of recovery times proportional to volume size vs. proportional to I/O rate).
>The Journaled File System (JFS) was created by IBM.
"JFS" is an IBM thing, and may have been the first commercially available journaling filesystem (certainly for UNIX) but there were others working on essentially the same thing at the same time or perhaps even a little before.
One thing that people seem to be confused about here is journaling vs. log-structured filesystems. A journaling filesystem only logs metadata ("data about data") such as file sizes and allocation maps. The actual file contents are "someone else's problem" just as in a traditional fsck-style filesystem. A log-based filesystem is much weirder. Everything including file data is logged, and once you have a complete log, well, why do you need anything else? So the data exists _only_ in the log, and their a pruner process used to get rid of old log data that has since been overwritten so that space can be reused, etc. It sounds like it would never work, I know, but it can actually work very well depending on your read/write mix.
>I, like others, suspect that when they said `logging,' they meant a journalling file system. Why don't you do a technical comparision of JFS and ext2fs and tell me what conclusion you come to now?
While you're doing that evaluation, don't forget that ext2fs relies on asynchronous metadata updates to get performance, meaning that if you crash your metadata is not guaranteed even to be consistent (let alone reasonably current). Furthermore, the penalty for enabling synchronous metadata updates is - according to the _authors_ - "undetected data corruption". Even worse.
>Even if they were talking about journaling, NT doesn't do that either
Journaling is an integral part of NTFS. More FUD.
>Linux DOES do SMP
Yeah, so does NT. Neither does it well, though Linux does it better than NT does.
MSNBC, Your One Source for Biased Communications.
on
WSJ Says Linux Lags
·
· Score: 1
>Slashdot has NEVER been a source of FUD against Microsoft
Bull. I've seen more lies about Microsoft propagated on slashdot than I've ever seen lies about Linux propagated by Microsoft. Sometimes it seems slashdot is nothing _but_ FUD about all alternatives to Linux.
Slashdot Mirror
Cool. I'm in the same situation (cable for the computer, not for the TV) and I always thought it was just a harmless annoyance having MediaOne call up every couple of months for a customer survey about service I don't have. It looks like the problems could be more serious.
;-)
Fortunately (?) I'm moving outside of MediaOne's service area soon, so I'll just hope I make it until then without being indicted.
Ahh, the old myth that "everyone's needs are [or should be] like mine".
A good network connection is sufficient if you can delete something when you need the space and then get it again off the net. This implies that _someone_ stored it. Now, if all you're doing is downloading content (including programs) generated by someone else, that's probably true, but who's going to store the content _you_ create, and on what are they going to store it? Mere users and creators who are content to freeload off someone else's storage can use the approach you espouse, but it doesn't work otherwise.
There are other reasons your approach is not universal. Transferring files is an example. Sure, if the connections at both ends and everything in between are all fast, maybe it'll work. But what if you have to work at a different site and they don't allow outside network connections (either physically or via firewall restrictions)? What if you want to leave your home machine powered off but still take your data to work? What if you want to give the files _you created_ to someone who doesn't have such a fast connection? What if you'd rather pay _one time_ for the drive and henceforth pay less for media than the monthly charge for the fast net connection? Or are you freeloading there too?
Lastly, a lesson from Tannenbaum: "never underestimate the bandwidth of a station wagon full of tapes". My employer has multiple OC-12 and better connections to the net (we dabble in 24/7 e-commerce hosting) and I _still_ never see network transfer rates comparable to disk transfer rates.
>I'll just stick to CD-RW. At least then I'll be sure anyone will be able to read the media.
Not all CD-ROMs are happy with CD-RW media. Never had a problem with CD-R, though.
Also, all compatibility goes out the window if you use UDF (e.g. Adaptec DirectCD) instead of more traditional formats.
I don't think this is accurate. I've heard such claims for an actual _cut_ CD such as what your software comes on, but not for CD-R. AFAIK, the most stable medium writable by something you can put inside your desktop machine is MO.
Everyone knows that "lines of code" in the sense of the output from "wc -l" is totally useless as a measure of anything. That's just a strawman. Most "lines of code" measures at least take some account of braces and comments (though there's debate about whether it's fair to exclude comments) and some even take account of statement complexity to yield a _somewhat_ useful measure of productivity. But even finding fault with that is little better than attacking a strawman, because anyone with an ounce of sense knows that _any_ measure based solely on the code itself is likely to be inaccurate.
Any idiot can write 20K lines of code a year. It gets harder if you're only counting _properly debugged_ lines of code. It gets harder if you have to design whatever it is you're coding, and document the design, and have code reviewed, etc. It gets harder when what you're writing is intrinsically hard, such as a compiler or OS instead of GUI eye-candy. If the standards for non-coding activities are not held constant, the coding numbers are meaningless, and you can never really compare different types of code. I've worked with some people regarded as superstars within the industry, and very few of them can sustain a coding rate of even 50 lines of well-written, well-debugged, designed-from-scratch and reviewed kernel code per day. That's only 12.5K lines per year, but worth far more than 25K lines of derivative user-level crap any day.
Now the irony part. From the article:
>One alternative is to tap reusable software components and object technologies to improve software development productivity
Think about it. Reusable code does improve _real_ productivity but by definition does not contribute to one's LOC numbers. It would be entirely reasonable to suppose that part of the reasons for US programmers' low numbers might be precisely because they _do_ take advantage of code reuse. Padding LOC numbers by writing a new version of something that already existed, because you didn't know any better, is a failing typical of very junior software engineers; more experienced hands know better.
For the authors of this article to criticize US programmers' "lack of productivity" using LOC, and then suggest code reuse as a solution, only shows their own ignorance.
>However, he was there first and did much to put MIT on the map for Software Engineering.
Did much? Certainly, but let's not forget the many others who were involved in incubating the "hacker culture" there.
There first? _Definitely_ not. Try to keep your hero-worship within the bounds we call "reality".
The old logo was language-independent, time-independent, and just...well, cool. The new logo bites.
College works for some people. Self-teaching works for some people. The one thing that's pretty much guaranteed is that someone who has both a college education _and_ real-world experience is more likely to be competent than someone who only has one or the other. Employers would rather go for the almost-sure bet than for either alternative where _maybe_ it will work out but the odds are worse, and employers certainly don't have any inclination to check out the specific circumstances of each and every individual candidate. Looking for both is an heuristic ("rule of thumb" for those who didn't go to college) that works pretty well overall.
I'd also like to make a point about those people who say "lack of a degree never held me back". First off, you would have learned in a statistics class that anecdotal evidence isn't generalizable. Secondly, one of the lessons you might have learned by studying either evolutionary biology or graph theory has to do with local optima and dead ends. Maybe your lack of a degree hasn't held you back..._yet_. Maybe you think you're climbing that mountain just fine, until you realize that your chosen approach brings you to an insurmountable cliff wall and your only choice will be to backtrack. I've seen people who've had to backtrack career-wise because they had thought they could skip learning some technique or technology. It's not pretty, and they didn't enjoy it much.
College may lead you in some pretty useless directions sometimes, but that 30000-foot view may come in handy when you can't see the terrain from the ground.
>Most of my friends do SysAdmin and Tech Support - and they usually know a lot more than the developers and consultants I have to work with.
I hear this claim a lot, and it's almost never true. What you probably mean is that they know less about _what you think it's important to know_ (e.g. system administration or tech support) _for your job_. My mother still asks me about Word macros and ICQ, because she knows I'm in computers and lacks the knowledge to distinguish a GUI/VB slob from a UNIX kernel hacker. Likewise, I'd say that very few sysadmins would be able to distinguish a great developer from a mediocre one even if they both slapped him (or her) in the face. You have your specialty, we have ours, and it's generally fair to judge each other by the same standards we'd use for those in our own field.
>I hope someday you realize the futility of silence, Jeff.
Oh, I know the futility of silence. What makes you assume I'm silent about issues that need to be addressed? This particular instance is a poor example of how I deal with such cases, since the only "wrong" thing D.H.Brown has done is provoke the knee-jerk reactions of a bunch of lightweights. When I care, I act.
My intent, beyond a little light-hearted fun, was to point out that if you want to be heard you'll have to do something better than identify yourself as a "Systems Designer" at some company nobody ever heard of. Why should they not assume that TekConnect is just another "vanity company" that only really exists at the local registrar's office? Why should they do anything but laugh at your threat never to buy any of their research when the probability was practically nil anyway? Don't explain the answers to me; explain to them.
Lacking anything more convincing than a made-up job title, it's hard to see your post as being truly aimed at getting results from D.H.Brown. Seems a lot more like dressing up in corporate-big-shot drag for the benefit of the kiddies here who don't realize how easy it is to fake these sorts of things.
>Congratulations! You have just assured that my company will never purchase any of your so-called "research".
>
>Systems Designer
>TekConnect Corporation
I'm sure that scared them.
Jeff Darcy
Founder, Systems Designer, and Chief Bottlewasher
SuperWhizBangTek.com
>You can't get highly-available failover clusters with Linux. [though the linux-HA project is working on it]
Progress on this has been glacially so. That may be because the primary author was scared off when I, as one of the authors of the commercial product he was blatantly and transparently ripping off (he makes his living as a support engineer for that product, and had taken classes I had taught), sent him some email a while ago.
Or maybe it's because HA is a hard problem, and there seems to be a much greater interest in the Linux community in dicking around with themes and other brain candy than in solving hard problems.
>Alternatively, one could write a ufs/ffs for Linx
UFS/FFS is not a journaling filesystem, and does not solve the problems that journaling was invented to solve (primarily that of recovery times proportional to volume size vs. proportional to I/O rate).
>The Journaled File System (JFS) was created by IBM.
"JFS" is an IBM thing, and may have been the first commercially available journaling filesystem (certainly for UNIX) but there were others working on essentially the same thing at the same time or perhaps even a little before.
One thing that people seem to be confused about here is journaling vs. log-structured filesystems. A journaling filesystem only logs metadata ("data about data") such as file sizes and allocation maps. The actual file contents are "someone else's problem" just as in a traditional fsck-style filesystem. A log-based filesystem is much weirder. Everything including file data is logged, and once you have a complete log, well, why do you need anything else? So the data exists _only_ in the log, and their a pruner process used to get rid of old log data that has since been overwritten so that space can be reused, etc. It sounds like it would never work, I know, but it can actually work very well depending on your read/write mix.
>But I'd like to see next year's report, when they analyze Linux with a distro using the 2.2.x kernel. Then we'll see.
Don't get your hopes up. "Less bad" is the phrase I'd use.
Looks a hell of a lot like what I got used to seeing on AIX. I had to look back at the start of the article to make sure that's not what it was.
>I, like others, suspect that when they said `logging,' they meant a journalling file system. Why don't you do a technical comparision of JFS and ext2fs and tell me what conclusion you come to now?
While you're doing that evaluation, don't forget that ext2fs relies on asynchronous metadata updates to get performance, meaning that if you crash your metadata is not guaranteed even to be consistent (let alone reasonably current). Furthermore, the penalty for enabling synchronous metadata updates is - according to the _authors_ - "undetected data corruption". Even worse.
More FUD.
>AIX: Logging Sucks.
>Linux: Logging Rules.
>NT: NT does logging?
I'm not sure exactly what kind of logging you're talking about, but I can't think of any definition by which AIX does less/worse than Linux.
>Even if they were talking about journaling, NT doesn't do that either
Journaling is an integral part of NTFS. More FUD.
>Linux DOES do SMP
Yeah, so does NT. Neither does it well, though Linux does it better than NT does.
>Slashdot has NEVER been a source of FUD against Microsoft
Bull. I've seen more lies about Microsoft propagated on slashdot than I've ever seen lies about Linux propagated by Microsoft. Sometimes it seems slashdot is nothing _but_ FUD about all alternatives to Linux.