There's a big difference between a kernel panic and simply stalling during the boot process on a screen which happens to be a shade of blue.
The Windows BSOD is the equivalent of a kernel panic, i.e. it's an unrecoverable error detected by the kernel. In XP and 2003 the default setting is to automatically reboot (possibly after dumping a contents of kernel memory) so one doesn't normally see it for any length of time. It looks like this (or if you'd prefer, like this).
The "blank blue screen" while the system is starting up or logging in isn't normally referred to as a "Blue Screen of Death", it's just a crappy buggy OS hanging in a way which makes it dang difficult to identify what the actual problem is.
I think he's retired. His successor is a drinking bird that periodically presses the "Approve submission" button on whichever article is currently pending approval.
I also thought it was pretty good. If you don't understand it, chances are it's probably not interesting to you, so just ignore it. You might also note that this is on developers.slashdot.org, so it's pretty much blindingly obvious who the target demographic is. Not every developer (nor even every web developer) is going to care about it, but a lot of the draw of sites like slashdot is that it allows you to keep abreast of news in areas related to your field of interest, but not quite close enough to your core speciality that you'd find out about it from other sources.
The summary itself is also far better than most. We need more submitters like neutrino38.
Also, having re-read the summary, I have to take issue with your post. I believe I've been trolled, but just in case:
The use of so many acronyms without any background information
Let's see, acronyms... there's AMF obviously, which although it's never explained what it stands for, what it does is pretty clear: the format used by Flash Remoting -- the equivalent of AJAX for the Flash world (if you don't even know what AJAX is, get the fuck off developers./.). There's AMFPHP which can be inferred from context to be something to do with AMF (just covered), PHP, and the reverse engineering work that'd been done on AMF. Even if you can't infer that, it's linked to the fucking website, so enlightenment is a mere click away. Finally, there's RTMP and RPC. Any developer should know what RPC is, and the summary explains pretty clearly what RTMP is used for. Let's pretend you weren't referring to "W3C" or "HTTP" as being acronyms without any background information.
So really, there's only 3 not entirely common (in the development world) acronyms, and they're explained pretty succinctly in a manner which doesn't require you to understand anything specific to Flash. If you really had problems understanding the summary, then you should probably take some classes or something. Or at least, stay away from articles aimed at developers.
As for why you should care, Flash is the biggest impediment to an open and accessible web. It's also something that open standards people don't really have an answer to, to the best of my knowledge. Given the atrocious user experience of Java applets, and the horrible clunkiness and frailty of client-side DHTML, Flash is the only effective way to provide the kind of dynamic, interactive content the mass market wants on the web. So anything to do with Flash is a pretty big deal.
But again, if you don't know why you should care, then you probably don't care, and if a well-written, informative summary like this leaves you feeling angry and confused, maybe you shouldn't be here. You're not the intended audience, so quit trying to make people dumb things down so they're useless to the intended audience.
I think that's a good and useful distinction, and probably worth leaving it at that.
But, it almost seems like an arbitrary cutoff; there's no particular reason a Perl program couldn't be compiled into native machine code, it's just (much) easier not to. So it's like we're drawing the line between "programming" and "scripting" based on the details of a particular implementation of the operating environment. While that's fair enough, it seems like a pretty pointless distinction.
What happens if someone builds a hardware CPU that executes Java bytecode or that directly interprets and runs the Perl symbol structure. Would that suddenly make them programming languages and not scripting languages?
How about old console games? Aren't they compiled code designed to run on a particular CPU? What happens if they're run on a PC under an emulator? Do they become "scripting" because they're now being run by a pre-written program?
Well, I don't really have anything to add, but I do feel that dividing programming and scripting in that manner doesn't seem quite complete. Not that I can improve on it, of course.
On and off over the years I've had occasion to work with Microsoft developers on various things. "They" are just a bunch of guys, regular programmers, just like you find at every other big company in the world. [...] Nobody has a secret evil plan. It just doesn't exist. [...] there are so many different people involved, any such Evil Agenda would be exposed so quickly from the inside it would make your head spin. [...] execute these clever, evil plots.
Firstly, what do Microsoft's developers have to do with anything? Sure they write the code, but like you said, they bust their ass meeting deadlines and implementing what their managers tell them to implement, to the best of their ability. And they love it, of course, because why else would they be developers? But just because the guys that write the code don't have a master plan doesn't mean there isn't one.
Secondly, you keep using the term "evil". I'm not sure where you got that from. Also, treating the PP as some kind of "conspiracy theory" is kind of weird. Microsoft's management are paid to come up with and implement (or at least follow) plans that will make Microsoft money. That's their job, and I'd wager that most of them very much enjoy working out ways of leveraging their assets (such as IE and Windows) to improve the returns on other properties, and how to kill off the competition, and keep people on the Windows platform. There's nothing evil about this. It must be fascinating and exciting. Much like a military commander would enjoy examining the map of the battlefield, considering where his forces are, where the enemies (known) forces are, trying to imagine what they're planning and coming up with counters, etc. We make games about this stuff, because it's really fun - especially when you're winning! But of course, in the real world, if someone's winning than it usually means that someone else is losing.
Back on topic, of course Microsoft use MSIE as a tool to derail standardisation processes and keep people locked into their big money maker: the Windows OS. You don't have to be an evil genius to realise that the more people feel they're able to use alternative products, the more people will use alternative products. Leveraging IE and the tremendous market share of their core products in an effort to keep others from gaining ground against you isn't "evil" or "underhanded", it's just good business sense.
When your market share is the size of Microsoft's, interoperability only hurts you, because it makes it easier for others to replace your products. Interoperability is for the little guys. Most of us on/. want a world full of little guys who get along nicely, because that means you have consumer choice. Where there's choice, there's competition. And competition is what capitalism thrives on. So, wanting the browser with the largest market share to be compliant with standards and therefore a commodity item replaceable by any number of others isn't "anti-capitalism" at all.
Anyway, my point is: what about "leveraging IE to maintain or expand Microsoft's dominance in the PC market" requires an underhanded, secret or evil plot?
I can see how being able to copy and paste text from the shell to/from vim would be useful if you're not using it in an environment with an alternative copy/paste mechanism (e.g. a graphical window manager), but being able to compile and build files without leaving vim? What's wrong with Ctrl+Z?
Seems unlikely to find a person who meets all those criteria, much less one person per generation to continue the leadership. But run through that checklist with a computer system as your leader, and you have a strong candidate.
The catch, of course, is that computer systems are designed by humans. Also the inevitability that they will decide to destroy all humans.
what's it compile to? Don't forget that the value of $i may be undefined, a string, an integer, a float or a ref.
The GP's point was that the various things that Perl provides can be turned into assembler patterns too. The pattern that += 5 produces would be longer in Perl than in C, as it has to do existence and type checking etc., but it's still a pattern. Just because it's longer doesn't automatically mean it's orders of magnitudes more complicated once you understand it. It's just a bunch of simple things joined together.
Consider a C function add_two_things(val1, val2) which accepts two pointers and returns the result of adding them together. These pointers can point to a variety of different objects: strings, integers, floats, complex data types, or even NULL. This function needs to work out what type of thing both values are, convert them into compatible values, and return the result. You'd have no problem converting this C function into assembly language, right? And if you did, the pattern you'd end up with would be similar to that produced by compiling a Perl $i += 5.
So basically Perl is just higher level than C, in that it saves you writing a whole bunch of code. This is merely because of the definition of the language though. In C, "i += 5;" means "add the integer value 5 to the memory location i" if i is declared as an integer, or "add the floating point value 5.0 to the memory location i" if i is defined as a float. If i is undefined, then it's an error and the language definition says it's invalid code that can't be run.
In Perl, "$i += 5;" means something more like "if $i hasn't yet been defined, define it as an integer 0 and add 5 to it (unless 'use strict' is in effect), otherwise if it's any kind of numeric value add 5 to it, otherwise if it's a string to convert it into some kind of numeric value and add 5 to it". Plus a few other behaviours, probably. The assembly language pattern this produces would be much longer than the C pattern for "i += 5", but that's because they're not in any way equivalent. The assembly produced by add_two_things() would however be similar to the Perl equivalent.
Don't forget: the Perl interpreter is written in C, which implies anything you can do in Perl can be done in C, which implies it can be done in machine language.
Now, if Chandon Seldon was actually arguing that Perl isn't a higher level language than C then he, she, or it is nuts. The claim that Hand compiling is only moderately more complicated for Perl than it is for C depends on how good one is at hand compiling, I suppose. The code will certainly be longer, but all the stuff "$i += 5" does will repeated in any similar operation, and if you're good at assembly you're probably good dealing with big chunks of repeated code. But the difficulty here lies more in the volume of code you need to produce, not the actual production of it.
Unless the robot is a hot chick femmbot, in which case it should most definitely bend over to pick up heavy objects. It should also fail to get a proper grip the first time, necessitating a quick ass-wriggling repositioning while still bent over.
The logical place to draw the line is where the device cannot be used until you do something that isn't part of the normal operation of the device, or requires replacing non-user-serviceable parts. This makes it fairly easy to brick an mp3 or DVD player, as its normal operation is extremely limited. It's much harder to brick a PC, because as a general purpose computer built from a bunch of interchangeable components, "normal operation" of a PC covers a lot of things.
In this particular case, getting Windows to boot from the hard drive again simply requires booting the system from some other media (e.g. a Windows CD) to perform corrective actions (running a repair). Booting a PC from a CD is absolutely 100% part of its normal expected operation.
Moreover, the PC is clearly not "bricked", because it still boots and functions. The only thing that doesn't function properly is Windows. You could replace the hard disk (which is designed to be a user-replaceable component) and it would work fine. You can re-install it by booting from other media (which the device is explicitly designed and expected to do), and so on.
If you're still in doubt, consider if the Eve patch caused a particular application to no longer work (e.g. it removed some files required by Microsoft Office and which weren't looked after by the system recovery stuff in Windows). Would you then say the patch had "bricked Microsoft Office", because it no longer works without reinstalling (or at least repairing) Office? After all, there's a good chance the person using the computer wouldn't know how to repair or re-install Office, therefore it's "bricked" by the first definition.
In the case of an mp3 player, if it doesn't boot then it's probably bricked; since there the device is not designed to do anything else or be accessible in any other way. OTOH, if the device can be fixed by simply plugging it into a USB port on a computer (i.e. it's designed to be used as a mass storage device without having to boot the player OS) then it's not bricked.
So, in summary, replacing boot.ini with garbage does not "brick" Windows. It renders Windows unbootable, but they are two very different things, hence why we have two different terms. A PC could perhaps be bricked by having the BIOS go bad; but even then, motherboards are user-replaceable, so it's more accurate to call the motherboard bricked. It's virtually impossible to brick a "PC". If you have your drives on an add-on controller card and it dies, then the controller may well be bricked, but if you swap it with another card the PC as a whole will work just fine.
That level of CoD4 felt a bit forced to me because of the conversation from your partner. On the one hand it's trying to give you the feel of being an elite sniper on a high-risk mission deep in hostile territory - the kind of mission only the best of the best would be sent on. On the other hand, the team leader is talking to you like it's your character's first ever covert operation. I found that a bit jarring.
My understanding is that a lot of American phones are "feature locked" as well, i.e. certain features are disabled in order to force (coerce) you into using the higher-priced Telco features. I've heard really crazy sounding things like Bluetooth being disabled so you can't copy songs to the phone for free, you have to download them from your Telco. Is this hogwash, or does it have some basis in reality?
Also, the phone companies do care if you pay out the contract and leave; a lot of their market value is determined by the number of subscribers they have. While it's true they won't care about an individual subscriber leaving, they do care in the statistical sense.
I'm in Australia and the UK contracts sound similar to what we have. My latest phone (N73) is with 3, and interestingly enough they appear to subsidise the cost of the phone. I'm paying $22 a month for the handset over 2 years, which works out to be a little bit cheaper (around $100 IIRC) than buying it outright would have been. I guess there might be some trick with depreciation, but I was expecting to end up paying more for the phone over the period in exchange for the convenience of lower upfront costs.
I can't remember the exact terms of unlocking in my contract, nor even whether the phone is network locked at all (I think most consumers don't really care, if I didn't like the plan they offered I wouldn't have signed up for it). I think it's free after a certain period of time.
While your points are valid, you need to consider the harm that is done while the monopoly is let to run its course before it is eventually "routed around".
An extreme example: do we let the impoverished people in third world nations die of starvation on the theory that eventually the population will decrease to match the available food supply, and therefore resolve itself?
Obviously a monopoly isn't as detrimental to people as starving to death, but the point is that just letting it play out until it resolves itself results in people "suffering" for a period of time. Worse, the people "abusing" the market profit mightily during the period, which only serves to encourage others to do the same if at all possible.
The inevitable downfall of a monopoly isn't disincentive enough to discourage people. Microsoft's monopoly may only last 10 years, but during that 10 years the directors have made an absolute crapload of money, and there's a lot of people who dearly want to emulate Microsoft's "success". If the government (or whomever) regularly intervened before such behaviour become hugely profitable, then it would greatly decrease the incentives for others to follow suit.
On the other hand, I do agree that when people start to meddle to try to make things "better", it tends to make things worse more often than it makes it better. But it's probably also worth pondering whether Microsoft has actually held back on their monopolisation for fear of upsetting the government watchdogs. If there really was zero threat of government regulation interfering with them, would they have bought far more of their competitors than they have? Would they be pushing out patches via Windows Update that prevent Firefox and Opera from running on Windows? Would they make MSIE refuse to navigate to their websites altogether?
You can't create hard links spanning multiple volumes/filesystems, for the same reasons you can't on other operating systems. You also can't create a hard link to a directory.
Symlinks (junctions or reparse points) are a bit trickier, and made my brain hurt. Seems like you can only use them for directories, not individual files. I think your best bet is to use a SysInternals tool (junction) to manage them. This page has a bunch of information about Windows hard and soft links. This bit is particularly... odd:
Explorer's behavior on deleting a link depends on the amount of data in the target directory. There appears to be a threshold (in my tests, between 406 and 449 megabytes, on a partition with 3.42G capacity, with 1.73G used, after deleting the 449 meg), above which, Explorer will delete the contents under your symlink when you delete the symlink. Restoring the symlink from the Recycle Bin does not restore the deleted data. But below the volume threshold, Explorer does not delete the target's data, but flags it invisibly for final deletion! This means you can delete a symlink, and then still use the data formerly under it, until you empty the Recycle Bin. Then the contents of the targeted folder will vanish. There is no warning about this behavior.
I would kind of like to use symlinks to help manage our software archive (so we can list file it by vendor but also browse the filesystem by category, for example), but now I'm pretty much too scared.
When people start watching TV shows and movies on YouTube, you might have a point. Most of the stuff on youtube is "filler". You browse around and watch some funny things or whatever for a while when you're bored and at your computer. It's not that surprising that a lot of people do this; a lot of people get bored. But when these people want to watch a particular TV show or movie, do you think they go to YouTube?
Not to mention the fact there isn't high-quality video available on bittorrent for most of what's on YouTube, or that YouTube does a lot of marketing and has vastly more exposure than TPB.
That's a risk you take regardless of the language, and I'd be a lot more comfortable committing to something like Perl which has been around for a very long time and still has very strong advocates, rather than something like Ruby on Rails that's only recently become popular (not to mention PHP which only really seems to appeal to the lowest common denominator).
Perl has pretty much stood the test of time, though. There's a lot of people with "legacy" pre-.Net VB/ASP code, which at the time was hyped as the next big thing and the most efficient way of programming for Windows/IIS (like all things are). Now, you'd be hard pressed to find people who want to do that kind of work. That's a remarkably short lifespan for a programming language. Even with.Net -- which most people seem to quite like -- they're already up to 3.5 and certainly any pre-2.0 code would be considered "legacy" by most companies at this point... and it's only 5 years old!
Does your *EVERYTHING* include every single desktop and lapop used by staff? Most organisations (like ours) don't do any backups of individual PCs, because most of the data is unimportant (on the disc image used to build the system in the first place), and there's no guarantee that the system will be on when the backups run.
That does sometimes mean people lose data when their disc drive fails (saving on the desktop or My Docs), but that's their own fault; everyone is told that if they can't afford to lose the data, it must be saved to the network.
We use a similar scheme to you, except our nightlies are usually incrementals for things that support it; otherwise there's just too much data (not to mention our main fileserver array is really slow, and takes about 24 hours to backup the slightly over 1 TB of data on it). Over the weekend we run full backups, which are taken offsite, and the last one every month is archived.
I think their point is that Microsoft doesn't have significant competitors in the two areas in which they feel Microsoft had a monopoly: operating systems and browsers. Google produce neither (directly), and most of GOOG's value is in the search space, where Microsoft were never accused of having a monopoly in the first place.
Or in other words, the fact that General Electric has a market value around 340 billion dollars is irrelevant to the case against Microsoft. You could argue that Google has some relevance because all of their services are accessed via a web browser running on an OS.
Umm... how would you be accessing Google Maps if you don't have any cell coverage at all? How are they going to triangulate between towers you have no reception from?
I think you're trying to solve an entirely different problem.;)
You're absolutely right, but you need to consider that there are organisations that will pursue legal action on behalf of free software authors pro bono.
The question then is, how much is your business worth to you; how much are you willing to bet that nobody will come after you?
As another poster pointed out, the GPL is based on copyright law, which makes it difficult to wriggle out of. And if your company makes a habit of "outright abuse" of GPL'd code and gets to be even moderately successful, you're going to annoy a lot of people. All it takes is one of those people to have enough money to decide to make an example of you, or for a group of people to donate funds, or for an interested party to decide to get involved and your company will wind up facing lawsuits over multiple instances of wilful copyright violation.
If a substantial part of your income depends on selling those abuses of GPL, then you could easily find your business shut down overnight.
On the other hand; maybe nobody will notice, or at least nobody with the will to fight you. It probably depends a lot on whether your business is making enough money to make it likely the complainant will be able to recover their costs in a lawsuit. Especially since they're likely to have ample evidence backing them up, while you'll be struggling not to be found in contempt of court without incriminating yourself.
So it depends on how important the business is to you. Are you willing to risk it on a 1% chance of someone calling your bluff? A 2% chance? A 10% chance?
Am i better off just writing all of my own code from scratch?
If you intend to distribute your program to others, then yes, though you might want to investigate some other options first.
Write it all yourself. Pros: you can license it however the hell you want. Also, you'll understand how every bit of your program works in great detail. Cons: it takes longer, and you're probably not an expert at everything so some parts of the finished program might not be as good or well-tested as they could be if you used a library from someone else.
Use a commercial library. Pros: will probably be fine to distribute in binary form (but make sure you read the license for any library you're considering). Saves you time, and you probably get support from the author. Cons: costs money, may impose additional restrictions on what you can do (read the license carefully!)
Use GPL licensed code. Pros: you can see the code, others can see the code, if it's a project with even a moderate sized userbase it's likely to be high quality and well tested, and lots of people able to provide support for it. Cons: you have to release the code to your own program.
Use LGPL licensed code. Pros: same as for GPL code. Cons: you have to make it possible for people you distribute your program to to re-link your code with the LGPL library (e.g. newer version or one with bug fixes you can't be bothered shipping).
Use code under a more permissive license, e.g. BSD. Pros: same as for GPL code. Cons: not many. Normally they have an advertising/credit clause, but you're okay with that.
If there's particular GPL code you want to use, you could consider contacting the author directly (assuming you can establish a particular copyright holder) and explain what you want to do and see if they're willing to grant you use of their code under a different license. This can be a bit thorny: if they've accepted contributions from other people who haven't explicitly signed their copyright over to them, then the author does not have a legal right to re-license other people's work.
First though, I'd urge you to reconsider your aversion to the GPL. Chances are whatever you're doing isn't particularly unique and masterful, and you'll lose less than you'd think by making the code available.
Another "sneaky" tactic would be to consider who you're distributing the binaries to. You don't have to provide the source with them, only an offer (good for 3 years) to do so. So, if the people you're giving your small project to aren't likely to be interested in the source, you could take that gamble. You don't have to provide the source to anyone you didn't distribute your software to (but be aware that if you put it on a public web site, anybody can download it, and that's distribution). Just be prepared for the possibility that someone will ask for it, and be prepared to hand it over with a smile.
The Windows BSOD is the equivalent of a kernel panic, i.e. it's an unrecoverable error detected by the kernel. In XP and 2003 the default setting is to automatically reboot (possibly after dumping a contents of kernel memory) so one doesn't normally see it for any length of time. It looks like this (or if you'd prefer, like this).
The "blank blue screen" while the system is starting up or logging in isn't normally referred to as a "Blue Screen of Death", it's just a crappy buggy OS hanging in a way which makes it dang difficult to identify what the actual problem is.
I think he's retired. His successor is a drinking bird that periodically presses the "Approve submission" button on whichever article is currently pending approval.
I'm almost certain that's not the original article. Neat idea though. Maybe we need an elinkscache.com.
I also thought it was pretty good. If you don't understand it, chances are it's probably not interesting to you, so just ignore it. You might also note that this is on developers.slashdot.org, so it's pretty much blindingly obvious who the target demographic is. Not every developer (nor even every web developer) is going to care about it, but a lot of the draw of sites like slashdot is that it allows you to keep abreast of news in areas related to your field of interest, but not quite close enough to your core speciality that you'd find out about it from other sources.
The summary itself is also far better than most. We need more submitters like neutrino38.
Also, having re-read the summary, I have to take issue with your post. I believe I've been trolled, but just in case:
The use of so many acronyms without any background informationLet's see, acronyms... there's AMF obviously, which although it's never explained what it stands for, what it does is pretty clear: the format used by Flash Remoting -- the equivalent of AJAX for the Flash world (if you don't even know what AJAX is, get the fuck off developers./.). There's AMFPHP which can be inferred from context to be something to do with AMF (just covered), PHP, and the reverse engineering work that'd been done on AMF. Even if you can't infer that, it's linked to the fucking website, so enlightenment is a mere click away. Finally, there's RTMP and RPC. Any developer should know what RPC is, and the summary explains pretty clearly what RTMP is used for. Let's pretend you weren't referring to "W3C" or "HTTP" as being acronyms without any background information.
So really, there's only 3 not entirely common (in the development world) acronyms, and they're explained pretty succinctly in a manner which doesn't require you to understand anything specific to Flash. If you really had problems understanding the summary, then you should probably take some classes or something. Or at least, stay away from articles aimed at developers.
As for why you should care, Flash is the biggest impediment to an open and accessible web. It's also something that open standards people don't really have an answer to, to the best of my knowledge. Given the atrocious user experience of Java applets, and the horrible clunkiness and frailty of client-side DHTML, Flash is the only effective way to provide the kind of dynamic, interactive content the mass market wants on the web. So anything to do with Flash is a pretty big deal.
But again, if you don't know why you should care, then you probably don't care, and if a well-written, informative summary like this leaves you feeling angry and confused, maybe you shouldn't be here. You're not the intended audience, so quit trying to make people dumb things down so they're useless to the intended audience.
I think that's a good and useful distinction, and probably worth leaving it at that.
But, it almost seems like an arbitrary cutoff; there's no particular reason a Perl program couldn't be compiled into native machine code, it's just (much) easier not to. So it's like we're drawing the line between "programming" and "scripting" based on the details of a particular implementation of the operating environment. While that's fair enough, it seems like a pretty pointless distinction.
What happens if someone builds a hardware CPU that executes Java bytecode or that directly interprets and runs the Perl symbol structure. Would that suddenly make them programming languages and not scripting languages?
How about old console games? Aren't they compiled code designed to run on a particular CPU? What happens if they're run on a PC under an emulator? Do they become "scripting" because they're now being run by a pre-written program?
Well, I don't really have anything to add, but I do feel that dividing programming and scripting in that manner doesn't seem quite complete. Not that I can improve on it, of course.
Firstly, what do Microsoft's developers have to do with anything? Sure they write the code, but like you said, they bust their ass meeting deadlines and implementing what their managers tell them to implement, to the best of their ability. And they love it, of course, because why else would they be developers? But just because the guys that write the code don't have a master plan doesn't mean there isn't one.
Secondly, you keep using the term "evil". I'm not sure where you got that from. Also, treating the PP as some kind of "conspiracy theory" is kind of weird. Microsoft's management are paid to come up with and implement (or at least follow) plans that will make Microsoft money. That's their job, and I'd wager that most of them very much enjoy working out ways of leveraging their assets (such as IE and Windows) to improve the returns on other properties, and how to kill off the competition, and keep people on the Windows platform. There's nothing evil about this. It must be fascinating and exciting. Much like a military commander would enjoy examining the map of the battlefield, considering where his forces are, where the enemies (known) forces are, trying to imagine what they're planning and coming up with counters, etc. We make games about this stuff, because it's really fun - especially when you're winning! But of course, in the real world, if someone's winning than it usually means that someone else is losing.
Back on topic, of course Microsoft use MSIE as a tool to derail standardisation processes and keep people locked into their big money maker: the Windows OS. You don't have to be an evil genius to realise that the more people feel they're able to use alternative products, the more people will use alternative products. Leveraging IE and the tremendous market share of their core products in an effort to keep others from gaining ground against you isn't "evil" or "underhanded", it's just good business sense.
When your market share is the size of Microsoft's, interoperability only hurts you, because it makes it easier for others to replace your products. Interoperability is for the little guys. Most of us on /. want a world full of little guys who get along nicely, because that means you have consumer choice. Where there's choice, there's competition. And competition is what capitalism thrives on. So, wanting the browser with the largest market share to be compliant with standards and therefore a commodity item replaceable by any number of others isn't "anti-capitalism" at all.
Anyway, my point is: what about "leveraging IE to maintain or expand Microsoft's dominance in the PC market" requires an underhanded, secret or evil plot?
It's okay, you're on slashdot... we understand.
I can see how being able to copy and paste text from the shell to/from vim would be useful if you're not using it in an environment with an alternative copy/paste mechanism (e.g. a graphical window manager), but being able to compile and build files without leaving vim? What's wrong with Ctrl+Z?
Seems unlikely to find a person who meets all those criteria, much less one person per generation to continue the leadership. But run through that checklist with a computer system as your leader, and you have a strong candidate.
The catch, of course, is that computer systems are designed by humans. Also the inevitability that they will decide to destroy all humans.
$i += 5;
what's it compile to? Don't forget that the value of $i may be undefined, a string, an integer, a float or a ref.
The GP's point was that the various things that Perl provides can be turned into assembler patterns too. The pattern that += 5 produces would be longer in Perl than in C, as it has to do existence and type checking etc., but it's still a pattern. Just because it's longer doesn't automatically mean it's orders of magnitudes more complicated once you understand it. It's just a bunch of simple things joined together.
Consider a C function add_two_things(val1, val2) which accepts two pointers and returns the result of adding them together. These pointers can point to a variety of different objects: strings, integers, floats, complex data types, or even NULL. This function needs to work out what type of thing both values are, convert them into compatible values, and return the result. You'd have no problem converting this C function into assembly language, right? And if you did, the pattern you'd end up with would be similar to that produced by compiling a Perl $i += 5.
So basically Perl is just higher level than C, in that it saves you writing a whole bunch of code. This is merely because of the definition of the language though. In C, "i += 5;" means "add the integer value 5 to the memory location i" if i is declared as an integer, or "add the floating point value 5.0 to the memory location i" if i is defined as a float. If i is undefined, then it's an error and the language definition says it's invalid code that can't be run.
In Perl, "$i += 5;" means something more like "if $i hasn't yet been defined, define it as an integer 0 and add 5 to it (unless 'use strict' is in effect), otherwise if it's any kind of numeric value add 5 to it, otherwise if it's a string to convert it into some kind of numeric value and add 5 to it". Plus a few other behaviours, probably. The assembly language pattern this produces would be much longer than the C pattern for "i += 5", but that's because they're not in any way equivalent. The assembly produced by add_two_things() would however be similar to the Perl equivalent.
Don't forget: the Perl interpreter is written in C, which implies anything you can do in Perl can be done in C, which implies it can be done in machine language.
Now, if Chandon Seldon was actually arguing that Perl isn't a higher level language than C then he, she, or it is nuts. The claim that Hand compiling is only moderately more complicated for Perl than it is for C depends on how good one is at hand compiling, I suppose. The code will certainly be longer, but all the stuff "$i += 5" does will repeated in any similar operation, and if you're good at assembly you're probably good dealing with big chunks of repeated code. But the difficulty here lies more in the volume of code you need to produce, not the actual production of it.
Unless the robot is a hot chick femmbot, in which case it should most definitely bend over to pick up heavy objects. It should also fail to get a proper grip the first time, necessitating a quick ass-wriggling repositioning while still bent over.
The logical place to draw the line is where the device cannot be used until you do something that isn't part of the normal operation of the device, or requires replacing non-user-serviceable parts. This makes it fairly easy to brick an mp3 or DVD player, as its normal operation is extremely limited. It's much harder to brick a PC, because as a general purpose computer built from a bunch of interchangeable components, "normal operation" of a PC covers a lot of things.
In this particular case, getting Windows to boot from the hard drive again simply requires booting the system from some other media (e.g. a Windows CD) to perform corrective actions (running a repair). Booting a PC from a CD is absolutely 100% part of its normal expected operation.
Moreover, the PC is clearly not "bricked", because it still boots and functions. The only thing that doesn't function properly is Windows. You could replace the hard disk (which is designed to be a user-replaceable component) and it would work fine. You can re-install it by booting from other media (which the device is explicitly designed and expected to do), and so on.
If you're still in doubt, consider if the Eve patch caused a particular application to no longer work (e.g. it removed some files required by Microsoft Office and which weren't looked after by the system recovery stuff in Windows). Would you then say the patch had "bricked Microsoft Office", because it no longer works without reinstalling (or at least repairing) Office? After all, there's a good chance the person using the computer wouldn't know how to repair or re-install Office, therefore it's "bricked" by the first definition.
In the case of an mp3 player, if it doesn't boot then it's probably bricked; since there the device is not designed to do anything else or be accessible in any other way. OTOH, if the device can be fixed by simply plugging it into a USB port on a computer (i.e. it's designed to be used as a mass storage device without having to boot the player OS) then it's not bricked.
So, in summary, replacing boot.ini with garbage does not "brick" Windows. It renders Windows unbootable, but they are two very different things, hence why we have two different terms. A PC could perhaps be bricked by having the BIOS go bad; but even then, motherboards are user-replaceable, so it's more accurate to call the motherboard bricked. It's virtually impossible to brick a "PC". If you have your drives on an add-on controller card and it dies, then the controller may well be bricked, but if you swap it with another card the PC as a whole will work just fine.
That level of CoD4 felt a bit forced to me because of the conversation from your partner. On the one hand it's trying to give you the feel of being an elite sniper on a high-risk mission deep in hostile territory - the kind of mission only the best of the best would be sent on. On the other hand, the team leader is talking to you like it's your character's first ever covert operation. I found that a bit jarring.
He did! What an insensitive clod!
My understanding is that a lot of American phones are "feature locked" as well, i.e. certain features are disabled in order to force (coerce) you into using the higher-priced Telco features. I've heard really crazy sounding things like Bluetooth being disabled so you can't copy songs to the phone for free, you have to download them from your Telco. Is this hogwash, or does it have some basis in reality?
Also, the phone companies do care if you pay out the contract and leave; a lot of their market value is determined by the number of subscribers they have. While it's true they won't care about an individual subscriber leaving, they do care in the statistical sense.
I'm in Australia and the UK contracts sound similar to what we have. My latest phone (N73) is with 3, and interestingly enough they appear to subsidise the cost of the phone. I'm paying $22 a month for the handset over 2 years, which works out to be a little bit cheaper (around $100 IIRC) than buying it outright would have been. I guess there might be some trick with depreciation, but I was expecting to end up paying more for the phone over the period in exchange for the convenience of lower upfront costs.
I can't remember the exact terms of unlocking in my contract, nor even whether the phone is network locked at all (I think most consumers don't really care, if I didn't like the plan they offered I wouldn't have signed up for it). I think it's free after a certain period of time.
While your points are valid, you need to consider the harm that is done while the monopoly is let to run its course before it is eventually "routed around".
An extreme example: do we let the impoverished people in third world nations die of starvation on the theory that eventually the population will decrease to match the available food supply, and therefore resolve itself?
Obviously a monopoly isn't as detrimental to people as starving to death, but the point is that just letting it play out until it resolves itself results in people "suffering" for a period of time. Worse, the people "abusing" the market profit mightily during the period, which only serves to encourage others to do the same if at all possible.
The inevitable downfall of a monopoly isn't disincentive enough to discourage people. Microsoft's monopoly may only last 10 years, but during that 10 years the directors have made an absolute crapload of money, and there's a lot of people who dearly want to emulate Microsoft's "success". If the government (or whomever) regularly intervened before such behaviour become hugely profitable, then it would greatly decrease the incentives for others to follow suit.
On the other hand, I do agree that when people start to meddle to try to make things "better", it tends to make things worse more often than it makes it better. But it's probably also worth pondering whether Microsoft has actually held back on their monopolisation for fear of upsetting the government watchdogs. If there really was zero threat of government regulation interfering with them, would they have bought far more of their competitors than they have? Would they be pushing out patches via Windows Update that prevent Firefox and Opera from running on Windows? Would they make MSIE refuse to navigate to their websites altogether?
You can use "fsutil" to create hard links.
You can't create hard links spanning multiple volumes/filesystems, for the same reasons you can't on other operating systems. You also can't create a hard link to a directory.
Symlinks (junctions or reparse points) are a bit trickier, and made my brain hurt. Seems like you can only use them for directories, not individual files. I think your best bet is to use a SysInternals tool (junction) to manage them. This page has a bunch of information about Windows hard and soft links. This bit is particularly ... odd:
Explorer's behavior on deleting a link depends on the amount of data in the target directory. There appears to be a threshold (in my tests, between 406 and 449 megabytes, on a partition with 3.42G capacity, with 1.73G used, after deleting the 449 meg), above which, Explorer will delete the contents under your symlink when you delete the symlink. Restoring the symlink from the Recycle Bin does not restore the deleted data. But below the volume threshold, Explorer does not delete the target's data, but flags it invisibly for final deletion! This means you can delete a symlink, and then still use the data formerly under it, until you empty the Recycle Bin. Then the contents of the targeted folder will vanish. There is no warning about this behavior.I would kind of like to use symlinks to help manage our software archive (so we can list file it by vendor but also browse the filesystem by category, for example), but now I'm pretty much too scared.
When people start watching TV shows and movies on YouTube, you might have a point. Most of the stuff on youtube is "filler". You browse around and watch some funny things or whatever for a while when you're bored and at your computer. It's not that surprising that a lot of people do this; a lot of people get bored. But when these people want to watch a particular TV show or movie, do you think they go to YouTube?
Not to mention the fact there isn't high-quality video available on bittorrent for most of what's on YouTube, or that YouTube does a lot of marketing and has vastly more exposure than TPB.
Complain to your elected representatives, perhaps? Now THAT's thinking outside the box!
That's a risk you take regardless of the language, and I'd be a lot more comfortable committing to something like Perl which has been around for a very long time and still has very strong advocates, rather than something like Ruby on Rails that's only recently become popular (not to mention PHP which only really seems to appeal to the lowest common denominator).
Perl has pretty much stood the test of time, though. There's a lot of people with "legacy" pre-.Net VB/ASP code, which at the time was hyped as the next big thing and the most efficient way of programming for Windows/IIS (like all things are). Now, you'd be hard pressed to find people who want to do that kind of work. That's a remarkably short lifespan for a programming language. Even with .Net -- which most people seem to quite like -- they're already up to 3.5 and certainly any pre-2.0 code would be considered "legacy" by most companies at this point... and it's only 5 years old!
Does your *EVERYTHING* include every single desktop and lapop used by staff? Most organisations (like ours) don't do any backups of individual PCs, because most of the data is unimportant (on the disc image used to build the system in the first place), and there's no guarantee that the system will be on when the backups run.
That does sometimes mean people lose data when their disc drive fails (saving on the desktop or My Docs), but that's their own fault; everyone is told that if they can't afford to lose the data, it must be saved to the network.
We use a similar scheme to you, except our nightlies are usually incrementals for things that support it; otherwise there's just too much data (not to mention our main fileserver array is really slow, and takes about 24 hours to backup the slightly over 1 TB of data on it). Over the weekend we run full backups, which are taken offsite, and the last one every month is archived.
I think their point is that Microsoft doesn't have significant competitors in the two areas in which they feel Microsoft had a monopoly: operating systems and browsers. Google produce neither (directly), and most of GOOG's value is in the search space, where Microsoft were never accused of having a monopoly in the first place.
Or in other words, the fact that General Electric has a market value around 340 billion dollars is irrelevant to the case against Microsoft. You could argue that Google has some relevance because all of their services are accessed via a web browser running on an OS.
Umm... how would you be accessing Google Maps if you don't have any cell coverage at all? How are they going to triangulate between towers you have no reception from?
I think you're trying to solve an entirely different problem. ;)
You're absolutely right, but you need to consider that there are organisations that will pursue legal action on behalf of free software authors pro bono.
The question then is, how much is your business worth to you; how much are you willing to bet that nobody will come after you?
As another poster pointed out, the GPL is based on copyright law, which makes it difficult to wriggle out of. And if your company makes a habit of "outright abuse" of GPL'd code and gets to be even moderately successful, you're going to annoy a lot of people. All it takes is one of those people to have enough money to decide to make an example of you, or for a group of people to donate funds, or for an interested party to decide to get involved and your company will wind up facing lawsuits over multiple instances of wilful copyright violation.
If a substantial part of your income depends on selling those abuses of GPL, then you could easily find your business shut down overnight.
On the other hand; maybe nobody will notice, or at least nobody with the will to fight you. It probably depends a lot on whether your business is making enough money to make it likely the complainant will be able to recover their costs in a lawsuit. Especially since they're likely to have ample evidence backing them up, while you'll be struggling not to be found in contempt of court without incriminating yourself.
So it depends on how important the business is to you. Are you willing to risk it on a 1% chance of someone calling your bluff? A 2% chance? A 10% chance?
If you intend to distribute your program to others, then yes, though you might want to investigate some other options first.
If there's particular GPL code you want to use, you could consider contacting the author directly (assuming you can establish a particular copyright holder) and explain what you want to do and see if they're willing to grant you use of their code under a different license. This can be a bit thorny: if they've accepted contributions from other people who haven't explicitly signed their copyright over to them, then the author does not have a legal right to re-license other people's work.
First though, I'd urge you to reconsider your aversion to the GPL. Chances are whatever you're doing isn't particularly unique and masterful, and you'll lose less than you'd think by making the code available.
Another "sneaky" tactic would be to consider who you're distributing the binaries to. You don't have to provide the source with them, only an offer (good for 3 years) to do so. So, if the people you're giving your small project to aren't likely to be interested in the source, you could take that gamble. You don't have to provide the source to anyone you didn't distribute your software to (but be aware that if you put it on a public web site, anybody can download it, and that's distribution). Just be prepared for the possibility that someone will ask for it, and be prepared to hand it over with a smile.
(IANAL, and this is not legal advice.)