Considering that Google does software, for which the idea of patents is just ludicrous, whereas Apple does hardware, where patents are clearly much more applicable. To be honest, it would have been surprising if the two didn't disagree...
And tools. They write a lot of tools - the apps that the graphics artists use to create the games. Those level designers that are available for FPS games exist because they were orignally written to be used in-house by the publisher of the game to create the game itself.
Actually, most good programmers spend a large chunk of their time writing tools. Why would I generate the glue code between my VM and the native system by hand? It's boring, repetitive and very error prone. Far better to write a tool that generates the C code that implements the glue. Or why beat myself up trying to get make to handle my very complex build environment - write a tool to do the build instead, that accepts an input more inline with my company's Config Management policies.
The vast majority of things that we do as programmers are either highly repetitive, or highly error prone - far better to have the computer do it in these cases. The obvious result is that we should be trying to automate as much of our work as possible by writing tools. Games programmers are no different.
A5. Yes you are. BUT...
and I mean this respectfully: as you will be selling your box as an embedded utility, what do you have to lose by GPL'ing (or otherwise opening) your code? If you do things right, you will have:
I. a community of people that are willing to buy your box to start;
II. a community will want to tinker and make your product better, fast, and you get to incorporate the changes for the next versions of your product;
III. the respect of a lot of people. Yeeeessssss, but, I'm guessing he's going to have some DRM in there, hence the interest in obfuscation.
As one of those engineers that writes DRM systems, let me let you into a little trade secret. We, and our bosses, are well aware that any DRM schemes that we create will be cracked. We don't care. If it takes you 5 years to crack my system, then that DVD of Cars has already gone from costing $30 at Walmart, to costing $10. I win. Frankly, after 5 years, I don't care if you crack my system. Good grief, I probably don't care if you crack it in 1 year.
Jeremy Allison's analysis is false for this reason. It's not necessary for the system to be uncrackable for it to be secure. It just has to be sufficiently difficult to crack that the product loses it's value before being cracked.
Of course, none of this excuses the ridiculous efforts in the HD-DVD debacle, where the system was cracked in a matter of months, and the counter-measures in a matter of a couple of weeks. That reeks of a DRM system created by engineers that have never been pirates...
To give you an idea of state of the art DRM, here's how it's done by my company: 1) All DRM functions are done in a virtual machine that is based on a CPU of our own design, with it's own opcodes, ABI, memory management system, compiler, and debugger. We recreate this environment about once every two years.
It takes the pirates around about 2 years to reverse engineer the virtual machine, and then write a debugger for it. It then takes them another few months to reverse engineer the actual DRM program that runs in the virtual machine. Of course, at that point in time, we just download a different DRM algorithm, and it takes another few months for them to reverse engineer it. We play that game until our client gets sick and tired of having to update the DRM software all of the time, at which point, they cough up the money for the next generation VM - which stops the pirates for another two years whilst they reverse engineer and develop the debugging tools again.
The only products of ours that have been cracked, are products that are more than three years old - sometimes the client decides that financial losses due to piratage is less than the cost of a new DRM system.
All of that is just to say that DRM can in fact work.
Yup, if MS continue with this, they are going to get smacked down by anti-trust legislation... Whilst MS may be able to argue that Jamie himself cannot create a plugin for VS Express that circumvents the lockdown on VS Express whilst using VS Express, they are not allowed to block the distribution of such a product to third-parties, as that would be anti-competitive.
Seeing as Jamie is now using a full version of VS, thanks to his MVP award, even this weak limitation no longer exists. If MS persist with this, they are going to get their butt kicked in court.
Wait! You mean that there are actually Windows developers out there that DON'T have cygwin installed?!?! I'm... speachless. What do you do when you need access to all that Posix-y programming goodness that is out there? A port? Yikes! And scripting - without cygwin, you're obliged to learn the Windows Way(tm), which means you're left out in the cold if you ever find yourself on one of the ever growing unix systems out there.
Personally, I have never bothered with learning how to manipulate Windows. You learn unix, and then you install Cygwin if you should ever find yourself working on a Windows system.
Of interest, I have worked for 4 different companies in my programming career. All worked on Windows systems, because - well, until very recently, a Linux desktop was a pain in the butt, and Macs cost too much compared with a stripped down Dell. But every single company used Cygwin as part of the standard developper environment.
I feel your pain on the whole Eclipse thing. I HATE that IDE so badly. For goodness sake, if I want power, I'll do it on the command line. If I'm using an IDE, is so that I don't have to go insane configuring every last detail. Eclipse manages to take the worst of both worlds and merge them together seamlessly...
I seriously doubt that Microsoft have 95% penetration of the home OS market. That's their percentage when you take into account all of the beige boxes sitting under desks in offices all around the world. Linux and Mac have next to no penetration into that market.
On the other hand, when I look at the download statistics for the big Linux distributions, and the sales stats for the Mac, I would say that Microsoft is lucky if they have even 85% of the home market. That would be 15% of homes where mandating IE truly does exclude the user. That's quite a large chunk of potential customers to just throw away through laziness.
A classic example of hashes is storing account passwords on a computer. In general, the computer doesn't store the password, it stores a hash of the password. When you enter the password, a hash is calculated, and compared against the hash already stored on the computer's drive. If they match, you have correctly entered the password. So how, as a malicious hacker, can I gain access to your account if I just have the hash of your password? Well, these days, hackers precalculate a massive library of password hashes, linked against the original passwords. When they find a match with the password on your harddrive, they know what the original password is. Generating the library takes some time, and running through the database takes some time too (a few hours generally), but within a day, your password is cracked.
In this case, a malicious company could precalculate the hashes of all processes that they might be interested in. They will be able to verify if the hashes of these programs were detected by Warden. Now, you can argue the toss about whether the knowledge of which processes are running on your computer are sensitive or not, but at the end of the day, the hash is not going to hide your data from expert eyes.
You weren't really paying attention there were you? Point 2 for example. My whole point is that the documented API is not working the way that you expected. Bad docs? Bad code? Who cares, it's not working. Your approach apparently is to throw your hands in the air, and go and sulk in the corner. Someone that can reverse engineer the driver will be able to continue going forward.
Point 3. Again, the documented API isn't working. Is it a bug in your code, or a bug in their code? Only a reverse engineering session will give you the answer. If it's a bug in your code, you will know what's going wrong, and you'll be able to fix it quickly. If it's a bug in their code, you'll be able to produce a detailed bug report, which is much more likely to be addressed than some vaguely described symptoms.
"Something I haven't disagreed with. It is, however, far from _necessary_ for a non-trivial amount of coding work out there. Someone writing a low-usage web app doesn't need to know assembler.".
And I never said that someone that doesn't know the underlying architecture can't hack together something simple. If that's what you consider programming, well - you probably aren't producing very good code. Anyone that wants to be a good programmer needs to know about the underlying architecture. At least, that's Jeremy Allison's position, which I happen to share. But apparently you think you know more about what a good programmer needs to know than Jeremy
"Mr Allison's advice (and commentary) seems to be very much centred around writing high-performance server applications. Which is hardly surprising, given his background, but may not be equally applicable to all forms of coding (eg: writing GUI apps for GNOME or KDE today is probably quite different to writing X apps twenty+ years ago, and an intimate knowledge of the underlying hardware/OS is only really necessary if your code is performance-sensitive)."
So not true. A simple example. You're writing a video editting program that needs access to the graphics card. Sadly your code and the card's driver aren't playing nice together. You've read the docs, you think you're doing the right thing, no-one on the forums can give you any pointers. What do you do? Ideally, you'd have a look at the source code of the driver - the ultimate documentation, to see what the driver is expecting of you. Trouble is, you're coding against an NVidia graphics card, and the bastards don't give out the source code.
Well, I for one would flick on the debugger, and reverse engineer the driver, see what it's doing... Bit hard to do if you don't understand how the OS driver model is set up, or if you don't understand your processor's assembly language, or how compilers generate stack frames, manage memory access bla bla bla.
This is not some pie-in-the-sky, never happens kind of scenario. I work in an embedded environment. My company produces a library which requires that our partners implement an interface. Trouble is, when we try to integrate our code and their code, it doesn't work. I don't know how many times I've sat in meetings with colleagues and the client where the two sides argue over where the bug is. Happily for me, I don't ever have to do that. I simply tell the client where the bug is in their code, because I've reverse-engineered it, and identified the problem, to the point where I can often tell them things like "you're not incrementing the pointer in the second case of the switch statement". End of argument, and the bug is corrected within hours if not minutes. The only other option is black-box testing to identify what the client is doing wrong, and even then you can only tell them in general terms.
Yet another example. I have loads of colleagues that know how to write some html/javascript, and put it up on a web server. But when for whatever reason they can't create a correct session between their client device and the server, they are completely lost. No idea how routing works. No idea how NATs work. No idea how to use a packet sniffer to see whether the TCP connection is correctly established. In other words, no idea how to debug the system.
There is no coding job in the world where an understanding of the underlying architecture won't enable you to be more effective. You're code will be smaller, faster, you'll have more tools available when trying to debug a system, or doing integration. You'll even be able to copy algorithms that you only have in binary form.
I know this is way off topic, but I'd just like to correct a few misconceptions about the French "surrendering" during WWII. For starters, I don't know that it can justifiably be said that France ever surrendered. Certainly, they lost mainland France in a military defeat, but the colonies rallied behind the government in exile formed by De Gaulle. See here for more detail. It took a couple of years to get their ducks in a row, but after giving much aid in defeating the Nazis in Africa, and participating with forces numbering over 100 000 in the invasion of Italy, they were finally able to field over 400 000 troops for the Normandy landings. That doesn't sound much like a surrendered country to me...
I'll second that. I downloaded NeoOffice about 6 months back, and had sent off a donation within an hour or so of using it. I don't have MS Office on my Mac, and I've never noticed the "lack"...
Anyway, Apple is just having fun hitting back at what has, until recently, been considered as MS's strength. MS made a bucketload of money by selling the OS by itself. Inherently, this means that the OS has to be available to run on "open" hardware.
Apple has never done this. So they get the benefit of being able to block use of their OS on other systems, whilst being able to make use of the inherent business model of microsoft, and the openess of linux, to ensure that a Mac can run all 3. This is a direct consequence of the different business decisions taken by Apple and MS. It is as valid an advantage for macs as the fact that they aren't crippled by malware, or that things just work. Apple would be wrong to not point this out.
Why not? Simply because flatscreen monitors are quickly replacing CRT screens, and consumers will not accept going back. This means that anyone that is willing to replace each little LCD pixel with a recorder will be able to faithfully record the entire program.
Cost? One cheap LCD screen, + soldering gear + salary of one bore Russian hardware hacker for 3 months~= $10000
Admittedly, there will be a very small loss in quality, but this isn't the bad old days of analog VHS. Once we have the slightly degraded copy, it's encoded digitally, and there will be no further loss.
Furthermore, the price is sufficiently low that someone will do it just to annoy the MPAA.
The attack is always against the weakest point of the system. Flatscreen display technologies are inherently digital in nature, and hence inherently capable of being recorded digitally. As no-one is going to give up flat-panel displays, video DRM is dead before it's even really got started.
Which of course brings us back to the starting point of all DRM discussions: what's the point? It won't stop the pirates. But it will stop honest users from being able to transfer the media they have paid for to a new platform. No, no, no, you have to pay again!
One of these days, the public is going to figure this out, and DRM will be banned by law. Until then, I for one will be buying my DRM encumbered media, and then legally (as I have already paid for the media) downloading an unencumbered copy off the Net...
Interthread communications - the scheduler is going to become the bottleneck. Maybe a processor architecture with some serious scheduler support may be able to mitigate this?
Internally, most objects are going to need to be implemented as state machines. A formally correct state machine is no easy thing to create, particularly in most popular programming languages of today (C, C++, Java)
Still, these two problems are solvable with new CPU architectures and better compilers...
I'm not sure that someone explaining in detail to the slashdot community that they are an incompetent programmer can even be defined as a troll. It's just kinda... sad.
Let's count the strikes: 1) can't use vi/emacs 2) can't figure out how to open a.txt on a Mac 3) couldn't find TextEdit (I mean, come on!) 4) didn't have xcode installed (and wants to make us believe that they're a programmer!) 5) didn't think to install any of the 50 squillion X11 open source editors available out there...
Good grief.
Even my computer illeterate partner is capable of opening a.txt for editing on a Mac.
Personally I set up cscope to play nice with xcode - programming bliss, on a stick! Way, way nicer than egrep. Of course, if you aren't programming in c, cscope isn't much use to you...
Yup, couldn't agree more. Add me to the list of mac users that spend more time in Terminal than on the desktop. But, I do not want to have to fight my computer so that it talks to the new camera that I bought, or the new handicam. I want to plug the damn things in and have them work, straight away.
Something that the FOSS zealots forget, is that the Mac kernel is every bit as open-source as the Linux kernel. If you want to go kernel hacking you are more than welcome. From Tiger onwards, MacOSX also supports XWindows straight out of the box, so you can also indulge as much as you like in FOSS application development. And yes, the Mac comes with it's open source package managers too, just in case that's what pushes your buttons.
I have an old G3 iBook, which I recently decided to install Ubuntu Edgy-Eft on, to see where Linux was at. What was my experience? About two thirds of applications downloaded using the package manager didn't work. They crashed. Others were plain unavailable, because they depended on binaries that were x86-only. Standard system function, like setting the time/date, crashed. I could not get ruby to install at all, it just did not want to compile. Ubuntu would not recognise the existence of my iMac for sharing files. Worse than all of this, it was slow compared to MacOSX.
I played with the system for about 2 weeks before scrubbing the installation and returning to Tiger. Anyone that thinks that Linux is better than MacOSX has never used MacOSX
"And there are no men who up and quit because they want to change careers? Because that's what this is... changing careers. Not quitting working; just doing different work. Would you be just as judgemental (and gender-biased) if she'd decided to quit and go back to school for a law degree, because she discovered she'd rather be prosecuting slumlords?"
This is of course the core of the issue. men don't cop any flak whatsoever for having a tendency to up and leave when they want to change jobs. And the statistics say that they change jobs more than women. From the company's perspective, it doesn't matter that someone leaves because they were offered a bigger pay packet somewhere else, or because the person wanted to change careers, or because they wanted a job that permitted more family time, or because they've had enough working to make someone else money and have decided to set up shop themselves, or because they decided to have a baby. IT MAKES NO DIFFERENCE! the company is just as inconvenienced. But only one will see you discriminated against.
As a female programmer, with 12 years of experience, I have yet to see a single one of my female colleagues get promoted. Not one. We generally have to change jobs to move up the ladder. And yet we are all very competent - women do not choose IT as a career unless they are really good at it. For me, that is where the discrimination lies - not in recruitment, but in promotions. Does anyone else out there have a similar experience?
Slashdot Mirror
Ohmigod!!!! You're right! Patents supress competition! Quick, call the papers!
Oh, hang on, what's that you say? Patents are supposed to supress competition? Oh, never mind then...Considering that Google does software, for which the idea of patents is just ludicrous, whereas Apple does hardware, where patents are clearly much more applicable. To be honest, it would have been surprising if the two didn't disagree...
No, the other half are women!
And tools. They write a lot of tools - the apps that the graphics artists use to create the games. Those level designers that are available for FPS games exist because they were orignally written to be used in-house by the publisher of the game to create the game itself.
Actually, most good programmers spend a large chunk of their time writing tools. Why would I generate the glue code between my VM and the native system by hand? It's boring, repetitive and very error prone. Far better to write a tool that generates the C code that implements the glue. Or why beat myself up trying to get make to handle my very complex build environment - write a tool to do the build instead, that accepts an input more inline with my company's Config Management policies.
The vast majority of things that we do as programmers are either highly repetitive, or highly error prone - far better to have the computer do it in these cases. The obvious result is that we should be trying to automate as much of our work as possible by writing tools. Games programmers are no different.
Actually, pharyngula has moved over to http://scienceblogs.com/pharyngula/
Ahhh, someone hasn't read their Schneier...
As one of those engineers that writes DRM systems, let me let you into a little trade secret. We, and our bosses, are well aware that any DRM schemes that we create will be cracked. We don't care. If it takes you 5 years to crack my system, then that DVD of Cars has already gone from costing $30 at Walmart, to costing $10. I win. Frankly, after 5 years, I don't care if you crack my system. Good grief, I probably don't care if you crack it in 1 year.
Jeremy Allison's analysis is false for this reason. It's not necessary for the system to be uncrackable for it to be secure. It just has to be sufficiently difficult to crack that the product loses it's value before being cracked.
Of course, none of this excuses the ridiculous efforts in the HD-DVD debacle, where the system was cracked in a matter of months, and the counter-measures in a matter of a couple of weeks. That reeks of a DRM system created by engineers that have never been pirates...
To give you an idea of state of the art DRM, here's how it's done by my company:
1) All DRM functions are done in a virtual machine that is based on a CPU of our own design, with it's own opcodes, ABI, memory management system, compiler, and debugger. We recreate this environment about once every two years.
It takes the pirates around about 2 years to reverse engineer the virtual machine, and then write a debugger for it. It then takes them another few months to reverse engineer the actual DRM program that runs in the virtual machine. Of course, at that point in time, we just download a different DRM algorithm, and it takes another few months for them to reverse engineer it. We play that game until our client gets sick and tired of having to update the DRM software all of the time, at which point, they cough up the money for the next generation VM - which stops the pirates for another two years whilst they reverse engineer and develop the debugging tools again.
The only products of ours that have been cracked, are products that are more than three years old - sometimes the client decides that financial losses due to piratage is less than the cost of a new DRM system.
All of that is just to say that DRM can in fact work.
Yup, if MS continue with this, they are going to get smacked down by anti-trust legislation... Whilst MS may be able to argue that Jamie himself cannot create a plugin for VS Express that circumvents the lockdown on VS Express whilst using VS Express, they are not allowed to block the distribution of such a product to third-parties, as that would be anti-competitive.
Seeing as Jamie is now using a full version of VS, thanks to his MVP award, even this weak limitation no longer exists. If MS persist with this, they are going to get their butt kicked in court.
Wait! You mean that there are actually Windows developers out there that DON'T have cygwin installed?!?! I'm ... speachless. What do you do when you need access to all that Posix-y programming goodness that is out there? A port? Yikes! And scripting - without cygwin, you're obliged to learn the Windows Way(tm), which means you're left out in the cold if you ever find yourself on one of the ever growing unix systems out there.
Personally, I have never bothered with learning how to manipulate Windows. You learn unix, and then you install Cygwin if you should ever find yourself working on a Windows system.
Of interest, I have worked for 4 different companies in my programming career. All worked on Windows systems, because - well, until very recently, a Linux desktop was a pain in the butt, and Macs cost too much compared with a stripped down Dell. But every single company used Cygwin as part of the standard developper environment.
I feel your pain on the whole Eclipse thing. I HATE that IDE so badly. For goodness sake, if I want power, I'll do it on the command line. If I'm using an IDE, is so that I don't have to go insane configuring every last detail. Eclipse manages to take the worst of both worlds and merge them together seamlessly...
May His Great Noodliness banish thee to the realms of meat and three veg for yet another car anolgy. No parmesan for you!
I seriously doubt that Microsoft have 95% penetration of the home OS market. That's their percentage when you take into account all of the beige boxes sitting under desks in offices all around the world. Linux and Mac have next to no penetration into that market.
On the other hand, when I look at the download statistics for the big Linux distributions, and the sales stats for the Mac, I would say that Microsoft is lucky if they have even 85% of the home market. That would be 15% of homes where mandating IE truly does exclude the user. That's quite a large chunk of potential customers to just throw away through laziness.
A classic example of hashes is storing account passwords on a computer. In general, the computer doesn't store the password, it stores a hash of the password. When you enter the password, a hash is calculated, and compared against the hash already stored on the computer's drive. If they match, you have correctly entered the password. So how, as a malicious hacker, can I gain access to your account if I just have the hash of your password? Well, these days, hackers precalculate a massive library of password hashes, linked against the original passwords. When they find a match with the password on your harddrive, they know what the original password is. Generating the library takes some time, and running through the database takes some time too (a few hours generally), but within a day, your password is cracked.
In this case, a malicious company could precalculate the hashes of all processes that they might be interested in. They will be able to verify if the hashes of these programs were detected by Warden. Now, you can argue the toss about whether the knowledge of which processes are running on your computer are sensitive or not, but at the end of the day, the hash is not going to hide your data from expert eyes.
You weren't really paying attention there were you? Point 2 for example. My whole point is that the documented API is not working the way that you expected. Bad docs? Bad code? Who cares, it's not working. Your approach apparently is to throw your hands in the air, and go and sulk in the corner. Someone that can reverse engineer the driver will be able to continue going forward.
Point 3. Again, the documented API isn't working. Is it a bug in your code, or a bug in their code? Only a reverse engineering session will give you the answer. If it's a bug in your code, you will know what's going wrong, and you'll be able to fix it quickly. If it's a bug in their code, you'll be able to produce a detailed bug report, which is much more likely to be addressed than some vaguely described symptoms.
"Something I haven't disagreed with. It is, however, far from _necessary_ for a non-trivial amount of coding work out there. Someone writing a low-usage web app doesn't need to know assembler.".
And I never said that someone that doesn't know the underlying architecture can't hack together something simple. If that's what you consider programming, well - you probably aren't producing very good code. Anyone that wants to be a good programmer needs to know about the underlying architecture. At least, that's Jeremy Allison's position, which I happen to share. But apparently you think you know more about what a good programmer needs to know than Jeremy
"Mr Allison's advice (and commentary) seems to be very much centred around writing high-performance server applications. Which is hardly surprising, given his background, but may not be equally applicable to all forms of coding (eg: writing GUI apps for GNOME or KDE today is probably quite different to writing X apps twenty+ years ago, and an intimate knowledge of the underlying hardware/OS is only really necessary if your code is performance-sensitive)."
So not true. A simple example. You're writing a video editting program that needs access to the graphics card. Sadly your code and the card's driver aren't playing nice together. You've read the docs, you think you're doing the right thing, no-one on the forums can give you any pointers. What do you do? Ideally, you'd have a look at the source code of the driver - the ultimate documentation, to see what the driver is expecting of you. Trouble is, you're coding against an NVidia graphics card, and the bastards don't give out the source code.
Well, I for one would flick on the debugger, and reverse engineer the driver, see what it's doing... Bit hard to do if you don't understand how the OS driver model is set up, or if you don't understand your processor's assembly language, or how compilers generate stack frames, manage memory access bla bla bla.
This is not some pie-in-the-sky, never happens kind of scenario. I work in an embedded environment. My company produces a library which requires that our partners implement an interface. Trouble is, when we try to integrate our code and their code, it doesn't work. I don't know how many times I've sat in meetings with colleagues and the client where the two sides argue over where the bug is. Happily for me, I don't ever have to do that. I simply tell the client where the bug is in their code, because I've reverse-engineered it, and identified the problem, to the point where I can often tell them things like "you're not incrementing the pointer in the second case of the switch statement". End of argument, and the bug is corrected within hours if not minutes. The only other option is black-box testing to identify what the client is doing wrong, and even then you can only tell them in general terms.
Yet another example. I have loads of colleagues that know how to write some html/javascript, and put it up on a web server. But when for whatever reason they can't create a correct session between their client device and the server, they are completely lost. No idea how routing works. No idea how NATs work. No idea how to use a packet sniffer to see whether the TCP connection is correctly established. In other words, no idea how to debug the system.
There is no coding job in the world where an understanding of the underlying architecture won't enable you to be more effective. You're code will be smaller, faster, you'll have more tools available when trying to debug a system, or doing integration. You'll even be able to copy algorithms that you only have in binary form.
I know this is way off topic, but I'd just like to correct a few misconceptions about the French "surrendering" during WWII. For starters, I don't know that it can justifiably be said that France ever surrendered. Certainly, they lost mainland France in a military defeat, but the colonies rallied behind the government in exile formed by De Gaulle. See here for more detail. It took a couple of years to get their ducks in a row, but after giving much aid in defeating the Nazis in Africa, and participating with forces numbering over 100 000 in the invasion of Italy, they were finally able to field over 400 000 troops for the Normandy landings. That doesn't sound much like a surrendered country to me...
I'll second that. I downloaded NeoOffice about 6 months back, and had sent off a donation within an hour or so of using it. I don't have MS Office on my Mac, and I've never noticed the "lack"...
Hypocritical? How so?
Anyway, Apple is just having fun hitting back at what has, until recently, been considered as MS's strength. MS made a bucketload of money by selling the OS by itself. Inherently, this means that the OS has to be available to run on "open" hardware.
Apple has never done this. So they get the benefit of being able to block use of their OS on other systems, whilst being able to make use of the inherent business model of microsoft, and the openess of linux, to ensure that a Mac can run all 3. This is a direct consequence of the different business decisions taken by Apple and MS. It is as valid an advantage for macs as the fact that they aren't crippled by malware, or that things just work. Apple would be wrong to not point this out.
As one of the aforementioned developers, amen to that! :-D
No. DRM on video will never work. Ever.
Why not? Simply because flatscreen monitors are quickly replacing CRT screens, and consumers will not accept going back. This means that anyone that is willing to replace each little LCD pixel with a recorder will be able to faithfully record the entire program.
Cost? One cheap LCD screen, + soldering gear + salary of one bore Russian hardware hacker for 3 months~= $10000
Admittedly, there will be a very small loss in quality, but this isn't the bad old days of analog VHS. Once we have the slightly degraded copy, it's encoded digitally, and there will be no further loss.
Furthermore, the price is sufficiently low that someone will do it just to annoy the MPAA.
The attack is always against the weakest point of the system. Flatscreen display technologies are inherently digital in nature, and hence inherently capable of being recorded digitally. As no-one is going to give up flat-panel displays, video DRM is dead before it's even really got started.
Which of course brings us back to the starting point of all DRM discussions: what's the point? It won't stop the pirates. But it will stop honest users from being able to transfer the media they have paid for to a new platform. No, no, no, you have to pay again!
One of these days, the public is going to figure this out, and DRM will be banned by law. Until then, I for one will be buying my DRM encumbered media, and then legally (as I have already paid for the media) downloading an unencumbered copy off the Net...
What a waste of time for nothing.
I see two problems with this solution:
Interthread communications - the scheduler is going to become the bottleneck. Maybe a processor architecture with some serious scheduler support may be able to mitigate this?
Internally, most objects are going to need to be implemented as state machines. A formally correct state machine is no easy thing to create, particularly in most popular programming languages of today (C, C++, Java)
Still, these two problems are solvable with new CPU architectures and better compilers...
I'm not sure that someone explaining in detail to the slashdot community that they are an incompetent programmer can even be defined as a troll. It's just kinda... sad.
.txt on a Mac
.txt for editing on a Mac.
Let's count the strikes:
1) can't use vi/emacs
2) can't figure out how to open a
3) couldn't find TextEdit (I mean, come on!)
4) didn't have xcode installed (and wants to make us believe that they're a programmer!)
5) didn't think to install any of the 50 squillion X11 open source editors available out there...
Good grief.
Even my computer illeterate partner is capable of opening a
Personally I set up cscope to play nice with xcode - programming bliss, on a stick! Way, way nicer than egrep. Of course, if you aren't programming in c, cscope isn't much use to you...
Yup, couldn't agree more. Add me to the list of mac users that spend more time in Terminal than on the desktop. But, I do not want to have to fight my computer so that it talks to the new camera that I bought, or the new handicam. I want to plug the damn things in and have them work, straight away.
Something that the FOSS zealots forget, is that the Mac kernel is every bit as open-source as the Linux kernel. If you want to go kernel hacking you are more than welcome. From Tiger onwards, MacOSX also supports XWindows straight out of the box, so you can also indulge as much as you like in FOSS application development. And yes, the Mac comes with it's open source package managers too, just in case that's what pushes your buttons.
I have an old G3 iBook, which I recently decided to install Ubuntu Edgy-Eft on, to see where Linux was at. What was my experience? About two thirds of applications downloaded using the package manager didn't work. They crashed. Others were plain unavailable, because they depended on binaries that were x86-only. Standard system function, like setting the time/date, crashed. I could not get ruby to install at all, it just did not want to compile. Ubuntu would not recognise the existence of my iMac for sharing files. Worse than all of this, it was slow compared to MacOSX.
I played with the system for about 2 weeks before scrubbing the installation and returning to Tiger. Anyone that thinks that Linux is better than MacOSX has never used MacOSX
"And there are no men who up and quit because they want to change careers? Because that's what this is... changing careers. Not quitting working; just doing different work. Would you be just as judgemental (and gender-biased) if she'd decided to quit and go back to school for a law degree, because she discovered she'd rather be prosecuting slumlords?"
This is of course the core of the issue. men don't cop any flak whatsoever for having a tendency to up and leave when they want to change jobs. And the statistics say that they change jobs more than women. From the company's perspective, it doesn't matter that someone leaves because they were offered a bigger pay packet somewhere else, or because the person wanted to change careers, or because they wanted a job that permitted more family time, or because they've had enough working to make someone else money and have decided to set up shop themselves, or because they decided to have a baby. IT MAKES NO DIFFERENCE! the company is just as inconvenienced. But only one will see you discriminated against.
As a female programmer, with 12 years of experience, I have yet to see a single one of my female colleagues get promoted. Not one. We generally have to change jobs to move up the ladder. And yet we are all very competent - women do not choose IT as a career unless they are really good at it. For me, that is where the discrimination lies - not in recruitment, but in promotions. Does anyone else out there have a similar experience?