FairPlay is about vendor lock-in first and foremost. Convincing the RIAA that it would have anything whatsoever to do with preventing piracy (which it clearly doesn't) is just marketing.
I love my iPod as much as the next Apple fanboy, but DRM sucks no matter who's peddling it.
The whole concept of 'Internet addiction' is pretty laughable, IMHO, and certainly using 'hours spent online per week' is completely useless from any scientific point of view.
How do you decide when someone is online or not? When their computer is running and connected to the net? In that case, I'm online 168 hours a week. I better get help immediately!
If you say it's 'hours spent using the Internet', that's no better. When I go to sleep at night, I like to listen to BBC news. No station in my area carries it, so I listen to it streaming from KERA in Dallas to an Airport Express and a small pair of speakers in my bedroom (where there is no computer). Am I thus 'using the Internet' while I'm lying there asleep? Certainly, there's a lot of network traffic going on, but I'm just listening to the frickin' radio!
What about if I'm just sitting at my computer playing Solitaire? Am I 'online' during that hour? What if, unbeknowst to me, my anti-virus fires up and downloads a new set of updates while I'm doing it?
The concept of 'an hour spent online' lacks any rigorous definition whatsoever. And people that spend a lot of time trying to do math with those made-up numbers make me wonder what it must have been like back when the telephone was invented. Surely the business world today is filled with people who would have been considered 'addicted to the telephone system' by similar pedants back in the early 20th century.
This is just academics trying to put numbers on things so they can get funded to do a study. Ignore them, and maybe they will go away.
The platform is too klugy, so there's always been reliability issues.
Erm, really? I've been a TiVo customer since almost the start--I've got two TiVo boxes of my own, and used a very-hacked third for years. I've seen problems with them, sure, but nothing I would blame on TiVo itself.
What sort of reliability issues are you talking about? Whatever they are, they're all news to me.
Now, TiVo's business prospects are a completely different matter, and I do fear they will die before the non-techie public realizes what they can do.
its not like you are looking at anything useful while you are fastforwarding
Sure I am. I do that all the time--for example, to get back a point in that show where I left it when my roommate watched all the way through, so it's not set at the right place when I go back to it. Or to fast-forward through most of the football game to find the place where that questionable call was so my buddies and I can argue about it.
So it really boils down to how big the popups are. If you can still easily see where you are in the program as you're zipping through it, then fine. But just like those @#&! channel logos and animated crawls networks have been putting accross the bottom of the screen the last several years, it seems obvious that the temptation to make them ever larger and more obnoxious will be very difficult to resist.
What about the exhaust given off from cars that are burning Mad Cow Fuels?
It, like the gasoline put into the car in the first place, will be composed of hydrocarbons vastly too short to be formed into prions.
Go read up on what refineries do and how they work. It will put your mind at ease about this 'threat', plus which it's a fascinating problem they have to solve. Every day a refinery doesn't blow itself to smithereens is a testament to the skill of the engineers who built it.
They offer it for $400 for the "lifetime" of the device.
Interestingly, even that may be on the way out. Four days ago, I installed a Samsung DirectTV/TiVo combo unit and called up DirectTV to activate it.
The lady on the phone told me in no uncertain terms that lifetime service was no longer available at any price. $5/month is the only option they offer now. I don't know if this applies only to the combo units or to TiVos as a whole.
News flash: 64-bit apps are, usually, slightly slower than 32-bit ones. Duh. Any developer who's been around 64-bit environments for more than a few weeks knows this. It's not like there's some subtle magic going on here; bigger pointers means more data to schlep around.
I think your parent's complaint is that is sort of like a cursory analysis indicating that triangular wheels aren't quite so good as round ones. If you really needed to be told this, you aren't in the audience that the article sounds like it's trying to address.
Certainly, many applications need 64 bits to operate. That doesn't mean it's the best tool for all jobs. The tone of the article sounds like it's exploring some big question that nobody's thought about before, and that's just silly.
When I got my first PS2, I already knew there were reliability problems with the drive. So I did something I never do: I got the extended replacement plan from Best Buy. I'm on my 3rd PS2 so far, both replacements on Best Buy's nickel.
But the really great part is that their replacement plan doesn't cover the price of a replacement unit--it covers the price you paid for it when you bought it. Sony keeps dropping the price of the PS2 over the years, so both times I've had to get a replacement, I got not only a brand new PS2, but enough money left over to pick up a game or two.
The only down side is that you have to live with no PS2 at all for a week or two while they process your return. But hey, I can live with that stress.
redesigning the internet would take away everything that makes it good.
Exactly. Anybody's who's been around Slashdot for more than five minutes should know enough to be terrified of the very idea.
A new design would inevitably reflect business motivations over technical ones at every turn. Say goodbye to the end-to-end concept, get ready for trivially-encrypted protocols just so that the DMCA can be used to force you to use 'authorized' clients that make you view advertisements left and right, expect to see some sort of licensing regime before you can even put up a public server somewhere, etc.
It's a good damn thing this is completely impossible, because it would be an absolute disaster if it happened.
I took it in 1992. He was an amazing professor--as eccentric as you'd imagine him to be. I remember him once asking us if any of us knew of a good place to get his worn Birkenstocks repaired.
He was the person who first made me realize--at a visceral level--that clear thought is as important in a program as clear prose is in writing a novel.
After the final exam (conducted verbally, one-on-one, at his home), he asked me what one thing I would most take away from his class. He seemed to consider my answer to this question more important than my performance on the test itself. I told him what the above about literature and programming. He nodded, thought for a bit, and said 'Very good. Can I offer you some tea before you go?'.
Once I was writing some C code to run on an old Motorolla DSP in an embedded system.
One particular function kept crashing. My debugging tools were very limited in this environment--basically, I had a total of 4 LEDs that I could blink on and off by insert function calls into my code. That and a logic analyzer for when things got really nasty.
Well, things did get really nasty. After reviewing and rewriting that function dozens of times, I finally decided the bug couldn't be in my C code. So I had the compiler spit out the assembly it was generating, brushed up on my DSP assembly, and read through its code on the hunch that there was a bug in the compiler (the compiler was very new and still pretty crappy).
But after spending a couple of days staring at the assembly, I concluded that it was perfectly fine. What else could be going wrong? I started thinking maybe something was going wrong in the link step or in the process of getting the file transferred down onto the embedded controller.
I went and learned more than I wanted to know about XCOFF format and used a little binary file editor to see what the linker output was. Again, everything just as it should be.
I just knew that somehow, what was getting executed was different from what was in the file. So we fired up the logic analyzer, and attached it to the DSP, and set it up to watch the contents of the address bus and data bus at each clock cycle.
This is incredibly painstaking--you have to look at 32 lines of step-functions to read off the address, and 48 lines of step-functions to read off the data (yes, it was a 48-bit data register; go figure) for EACH OPCODE. This will make your eyes bug out in a hurry.
But even then--nothing was wrong! The opcodes being loaded into the processor were exactly what they should be. But on this one particular test-and-branch instruction, the processor would just start to go crazy (address and data lines full of random noise; had to be powered down).
I dug out the processor manual and triple-checked the opcode name and number, addressing mode, and operands. Every bit was correct.
In utter frustration, we decided to call Motorolla to see if we could get some assistance from them. After going through a small maze of transfers, we finally ended up talking to the right person who knew (and quickly told us) that:
That particular addressing mode, when used with that particular
opcode, was known to throw the DSP into a hosed state.
It was a bug in the processor itself. The solution was simply to change my code to use a different addressing mode, and all was well.
Now MS tries to address subjects YOU WANT THEM TO ADDRESS, and the linux community is in an uproar
Who here do you think wanted MicroSoft to address DRM in the operating system? I'd guess almost nobody.
Who here do you think wanted MicroSoft to address the 'problem' of users having complete control over their own machines? Again, nobody.
I see no change in attitude here at all. The Slashdot crowd has always disliked DRM and giving Bill the keys to your computer--and that's exactly why there is so much anger at Palladium.
And while I agree with you that we'd be better off boosting Linux than trashing MicroSoft all the time, you still have to point out significant dangers when you see them.
Don't let the title fool you--although he uses C++ for his examples, the concepts he talks about (splitting code into components, why each component should be in its own file, levelization of components, etc.) make sense in any OO language.
I consider this book a must-read for anybody working on large programs.
For bugfixing or pounding out an implementation of an existing design, I have pretty much the same formula as everybody else seems to (massive caffeine overdose, dark, familiar music, and ZERO interruptions--work from home if you can).
But for design work, I find I do my best stuff in a completely different environment.
First of all, get away from your computer. If you're doing design, you should be envisioning shapes, graphs, and so on--you should not be thinking about code. Do not look at; do not touch it. Look at a whiteboard or stare at the sky while you're doing this.
Next, do something (other than caffeiene) to stimulate your metabolism. Play a few games of foosball, or take a shower, or have a cigar. I've done some of my best design work while standing in the shower.
Finally, let your subconscious work on it. Keep thinking about the problem as you go about your day, but don't stress out about not making any progress. A day or two into it, you'll have an epiphany and realize that it's all very simple.
"By reducing Windows to some undefined 'core operating system' the (states) would turn back the clock on Windows development by about ten years and effectively freeze it there," [Gates] said.
Well, in some sense, yeah. That's about the last time Windows was an operating system and just an operating system, as opposed to a forcibly-bundled OS, browser, media player, photo editor, etc., etc., isn't it?
I would desparately love to be able to read/. stories & comments via NNTP. The ability to kill some threads and use more advanced filtering (and killfiles!) like a real newsreader gives you would be highly valuable.
You'd have to charge for it differently than page views, of course, but I'd be happy to pay per KB or per comment for it.
Heck, considering that it would implicitly filter out ads also, I'd be willing to pay more than my current subscription price.
Did we watch the same movie?
on
Revolution OS
·
· Score: 2, Interesting
But the Stallman vs. Raymond/Perens debate forms the core of the movie.
Huh? That was in there, sure, but I definitely would not call it the core of the movie.
To me, it was about explaining how Linux came to be, what makes it different from proprietary software, and why the people that build it are willing to 'give away' their code.
And it does that fairly well, I think. For most of us, it's nothing we didn't already know, but I think it can go a long way to educating non-geeks about what's different and why we care.
The only problem I had with it was that it ended with the hi-tech market collapse and kind of implied that that was somehow the end of Linux. Those same non-geeks who would be informed by the first 90% of the movie could be seriously mislead by the last 10%.
Yikes! You have the process problems of a group five times your size.
If you have several people changing the same file in a given day, then one of two things (probably both) is wrong:
Coordination between features/projects. Somebody should be keeping an eye on the list of fixes/enhancements that are coming down the line and making sure you don't get too many in the same neck of the woods. This person doesn't necessarily have to be a developer (but should be able to speak developerese), and their whole job is to tell people, 'No, I'm sorry, but there's no room in the schedule for feature X that you want. Can I interest you in feature Y, which is in a different part of the code?'
Also, if your code is fairly big (more than a few hundred thousand lines), you need to break it into logical chunks and assign somebody to watch every checkin to each chunk. That person is a developer and responsible for making sure new code gets reviewed and unexpected changes aren't being made. If your code is smaller, one person can probably do that.
Code Architecture. If several functionally-unrelated features end up needing to change the same file, then something is wrong with that file. There's too much going on in it--you've got to be dilligent about keeping your components small and keeping each component in a separate file. See the excellent Lakos book for tips on how and why to do that.
Most likely, your organization went way too fast at some point in the course of setting up the core code architecture and the processes by which you decide what does and does not go into a release. You need to get started fixing both--or this problem will keep getting worse and worse until you're unable to move forward through your own inertia.
Assuming this is a scam, I went and looked at their section for investors. It's as terse as the rest of the site, but features the interesting disclaimer:
We regret that we cannot provide investment opportunities for any resident of Kansas.
What, Kansas has a law about selling perpetual motion machines or something?
Altruism is certainly part of it, I think, but there are many reasons:
Fun - A lot of us just plain like to tinker with our computers. Having the finished product is often less important than the act of writing it, so you may as well give it away when you're done.
Satisfaction - It's a bit of an ego-stroke, having something you've written be used by lots of people all over the world. That's how you know you did a good job.
Politics/Advocacy - Geeks can get pretty passionate about The Way Things Should Work. As programmers, we're uniquely able to actually make things work the way we want (at least on a practical level) sometimes. We'd be fools to pass up that chance.
Altruism - This is the most obvious one. Most people want to feel that in some small way, they've made a contribution to humanity. Writing a nifty little tool and giving to the world is hardly curing cancer or devoting your life to starving people in Calcutta, but it's something we can do that contributes (in however small a way) to the progress of technology as a whole. How could you not?
Slashdot Mirror
Pettifogger is pretty good. It doesn't have the "unqualified" connotation that quack does, but you get "underhanded" in exchange.
Guess again.
Dead wrong.
FairPlay is about vendor lock-in first and foremost. Convincing the RIAA that it would have anything whatsoever to do with preventing piracy (which it clearly doesn't) is just marketing.
I love my iPod as much as the next Apple fanboy, but DRM sucks no matter who's peddling it.
Yes.
Please stop perpetuating this myth. Apple have publicly stated that they would continue to use DRM even if the music labels didn't ask them to.
FairPlay is about stifling competition as much or more as it is about protecting copyrights.
The whole concept of 'Internet addiction' is pretty laughable, IMHO, and certainly using 'hours spent online per week' is completely useless from any scientific point of view.
How do you decide when someone is online or not? When their computer is running and connected to the net? In that case, I'm online 168 hours a week. I better get help immediately!
If you say it's 'hours spent using the Internet', that's no better. When I go to sleep at night, I like to listen to BBC news. No station in my area carries it, so I listen to it streaming from KERA in Dallas to an Airport Express and a small pair of speakers in my bedroom (where there is no computer). Am I thus 'using the Internet' while I'm lying there asleep? Certainly, there's a lot of network traffic going on, but I'm just listening to the frickin' radio!
What about if I'm just sitting at my computer playing Solitaire? Am I 'online' during that hour? What if, unbeknowst to me, my anti-virus fires up and downloads a new set of updates while I'm doing it?
The concept of 'an hour spent online' lacks any rigorous definition whatsoever. And people that spend a lot of time trying to do math with those made-up numbers make me wonder what it must have been like back when the telephone was invented. Surely the business world today is filled with people who would have been considered 'addicted to the telephone system' by similar pedants back in the early 20th century.
This is just academics trying to put numbers on things so they can get funded to do a study. Ignore them, and maybe they will go away.
Erm, really? I've been a TiVo customer since almost the start--I've got two TiVo boxes of my own, and used a very-hacked third for years. I've seen problems with them, sure, but nothing I would blame on TiVo itself.
What sort of reliability issues are you talking about? Whatever they are, they're all news to me.
Now, TiVo's business prospects are a completely different matter, and I do fear they will die before the non-techie public realizes what they can do.
Sure I am. I do that all the time--for example, to get back a point in that show where I left it when my roommate watched all the way through, so it's not set at the right place when I go back to it. Or to fast-forward through most of the football game to find the place where that questionable call was so my buddies and I can argue about it.
So it really boils down to how big the popups are. If you can still easily see where you are in the program as you're zipping through it, then fine. But just like those @#&! channel logos and animated crawls networks have been putting accross the bottom of the screen the last several years, it seems obvious that the temptation to make them ever larger and more obnoxious will be very difficult to resist.
It, like the gasoline put into the car in the first place, will be composed of hydrocarbons vastly too short to be formed into prions.
Go read up on what refineries do and how they work. It will put your mind at ease about this 'threat', plus which it's a fascinating problem they have to solve. Every day a refinery doesn't blow itself to smithereens is a testament to the skill of the engineers who built it.
Interestingly, even that may be on the way out. Four days ago, I installed a Samsung DirectTV/TiVo combo unit and called up DirectTV to activate it.
The lady on the phone told me in no uncertain terms that lifetime service was no longer available at any price. $5/month is the only option they offer now. I don't know if this applies only to the combo units or to TiVos as a whole.
But what's the fsking point?
News flash: 64-bit apps are, usually, slightly slower than 32-bit ones. Duh. Any developer who's been around 64-bit environments for more than a few weeks knows this. It's not like there's some subtle magic going on here; bigger pointers means more data to schlep around.
I think your parent's complaint is that is sort of like a cursory analysis indicating that triangular wheels aren't quite so good as round ones. If you really needed to be told this, you aren't in the audience that the article sounds like it's trying to address.
Certainly, many applications need 64 bits to operate. That doesn't mean it's the best tool for all jobs. The tone of the article sounds like it's exploring some big question that nobody's thought about before, and that's just silly.
May have been true once upon a time, but two words put the lie to this belief: broadcast flag.
When I got my first PS2, I already knew there were reliability problems with the drive. So I did something I never do: I got the extended replacement plan from Best Buy. I'm on my 3rd PS2 so far, both replacements on Best Buy's nickel.
But the really great part is that their replacement plan doesn't cover the price of a replacement unit--it covers the price you paid for it when you bought it. Sony keeps dropping the price of the PS2 over the years, so both times I've had to get a replacement, I got not only a brand new PS2, but enough money left over to pick up a game or two.
The only down side is that you have to live with no PS2 at all for a week or two while they process your return. But hey, I can live with that stress.
Exactly. Anybody's who's been around Slashdot for more than five minutes should know enough to be terrified of the very idea.
A new design would inevitably reflect business motivations over technical ones at every turn. Say goodbye to the end-to-end concept, get ready for trivially-encrypted protocols just so that the DMCA can be used to force you to use 'authorized' clients that make you view advertisements left and right, expect to see some sort of licensing regime before you can even put up a public server somewhere, etc.
It's a good damn thing this is completely impossible, because it would be an absolute disaster if it happened.
I took it in 1992. He was an amazing professor--as eccentric as you'd imagine him to be. I remember him once asking us if any of us knew of a good place to get his worn Birkenstocks repaired.
He was the person who first made me realize--at a visceral level--that clear thought is as important in a program as clear prose is in writing a novel.
After the final exam (conducted verbally, one-on-one, at his home), he asked me what one thing I would most take away from his class. He seemed to consider my answer to this question more important than my performance on the test itself. I told him what the above about literature and programming. He nodded, thought for a bit, and said 'Very good. Can I offer you some tea before you go?'.
I got an A, so I guess he liked my answer.
Once I was writing some C code to run on an old Motorolla DSP in an embedded system.
One particular function kept crashing. My debugging tools were very limited in this environment--basically, I had a total of 4 LEDs that I could blink on and off by insert function calls into my code. That and a logic analyzer for when things got really nasty.
Well, things did get really nasty. After reviewing and rewriting that function dozens of times, I finally decided the bug couldn't be in my C code. So I had the compiler spit out the assembly it was generating, brushed up on my DSP assembly, and read through its code on the hunch that there was a bug in the compiler (the compiler was very new and still pretty crappy).
But after spending a couple of days staring at the assembly, I concluded that it was perfectly fine. What else could be going wrong? I started thinking maybe something was going wrong in the link step or in the process of getting the file transferred down onto the embedded controller.
I went and learned more than I wanted to know about XCOFF format and used a little binary file editor to see what the linker output was. Again, everything just as it should be.
I just knew that somehow, what was getting executed was different from what was in the file. So we fired up the logic analyzer, and attached it to the DSP, and set it up to watch the contents of the address bus and data bus at each clock cycle.
This is incredibly painstaking--you have to look at 32 lines of step-functions to read off the address, and 48 lines of step-functions to read off the data (yes, it was a 48-bit data register; go figure) for EACH OPCODE. This will make your eyes bug out in a hurry.
But even then--nothing was wrong! The opcodes being loaded into the processor were exactly what they should be. But on this one particular test-and-branch instruction, the processor would just start to go crazy (address and data lines full of random noise; had to be powered down).
I dug out the processor manual and triple-checked the opcode name and number, addressing mode, and operands. Every bit was correct.
In utter frustration, we decided to call Motorolla to see if we could get some assistance from them. After going through a small maze of transfers, we finally ended up talking to the right person who knew (and quickly told us) that:
That particular addressing mode, when used with that particular
opcode, was known to throw the DSP into a hosed state.
It was a bug in the processor itself. The solution was simply to change my code to use a different addressing mode, and all was well.
Who here do you think wanted MicroSoft to address DRM in the operating system? I'd guess almost nobody.
Who here do you think wanted MicroSoft to address the 'problem' of users having complete control over their own machines? Again, nobody.
I see no change in attitude here at all. The Slashdot crowd has always disliked DRM and giving Bill the keys to your computer--and that's exactly why there is so much anger at Palladium.
And while I agree with you that we'd be better off boosting Linux than trashing MicroSoft all the time, you still have to point out significant dangers when you see them.
Don't let the title fool you--although he uses C++ for his examples, the concepts he talks about (splitting code into components, why each component should be in its own file, levelization of components, etc.) make sense in any OO language.
I consider this book a must-read for anybody working on large programs.
But for design work, I find I do my best stuff in a completely different environment.
First of all, get away from your computer. If you're doing design, you should be envisioning shapes, graphs, and so on--you should not be thinking about code. Do not look at; do not touch it. Look at a whiteboard or stare at the sky while you're doing this.
Next, do something (other than caffeiene) to stimulate your metabolism. Play a few games of foosball, or take a shower, or have a cigar. I've done some of my best design work while standing in the shower.
Finally, let your subconscious work on it. Keep thinking about the problem as you go about your day, but don't stress out about not making any progress. A day or two into it, you'll have an epiphany and realize that it's all very simple.
Well, in some sense, yeah. That's about the last time Windows was an operating system and just an operating system, as opposed to a forcibly-bundled OS, browser, media player, photo editor, etc., etc., isn't it?
I would desparately love to be able to read /. stories & comments via NNTP. The ability to kill some threads and use more advanced filtering (and killfiles!) like a real newsreader gives you would be highly valuable.
You'd have to charge for it differently than page views, of course, but I'd be happy to pay per KB or per comment for it.
Heck, considering that it would implicitly filter out ads also, I'd be willing to pay more than my current subscription price.
Huh? That was in there, sure, but I definitely would not call it the core of the movie.
To me, it was about explaining how Linux came to be, what makes it different from proprietary software, and why the people that build it are willing to 'give away' their code.
And it does that fairly well, I think. For most of us, it's nothing we didn't already know, but I think it can go a long way to educating non-geeks about what's different and why we care.
The only problem I had with it was that it ended with the hi-tech market collapse and kind of implied that that was somehow the end of Linux. Those same non-geeks who would be informed by the first 90% of the movie could be seriously mislead by the last 10%.
If you have several people changing the same file in a given day, then one of two things (probably both) is wrong:
- Coordination between features/projects. Somebody should be keeping an eye on the list of fixes/enhancements that are coming down the line and making sure you don't get too many in the same neck of the woods. This person doesn't necessarily have to be a developer (but should be able to speak developerese), and their whole job is to tell people, 'No, I'm sorry, but there's no room in the schedule for feature X that you want. Can I interest you in feature Y, which is in a different part of the code?'
- Code Architecture. If several functionally-unrelated features end up needing to change the same file, then something is wrong with that file. There's too much going on in it--you've got to be dilligent about keeping your components small and keeping each component in a separate file. See the excellent Lakos book for tips on how and why to do that.
Most likely, your organization went way too fast at some point in the course of setting up the core code architecture and the processes by which you decide what does and does not go into a release. You need to get started fixing both--or this problem will keep getting worse and worse until you're unable to move forward through your own inertia.Also, if your code is fairly big (more than a few hundred thousand lines), you need to break it into logical chunks and assign somebody to watch every checkin to each chunk. That person is a developer and responsible for making sure new code gets reviewed and unexpected changes aren't being made. If your code is smaller, one person can probably do that.
We regret that we cannot provide investment opportunities for any resident of Kansas.
What, Kansas has a law about selling perpetual motion machines or something?