You are right. Something is decidedly wrong on your system. It takes me, IIRC, under a second to go from "bootloader screen" to "kernel spitting out init data". It is definitely not twenty seconds.
Now, the time spent sitting in init scripts when a desktop could be brought up much faster and initscript loading continued in the background is an arguable issue...
If you dont believe my security statement, just wander on over to securitytracker.com - there are more discovered flaws in the recent past with Linux than with Windows.
a) Despite the increased amount of bundling Microsoft's done over the years, a "Linux distribution flaw" is still awfully different from a "Windows security flaw". A Linux distribution is composed of many, many more lines of code and pieces of software than Windows. If you want to include security problems with Open Office, it's only reasonable to include security problems with MS Office.
b) Local exploits attract attention on Linux. A lot of "exploits" in Linux are local attacks. Local security on a Windows box is pretty much a lost cause.
c) When Microsoft discovers a security problem and fixes it internally, they don't say "fixes a security hole in...". They just bundle it with some other set of fixes and stay quiet. You won't hear about it.
d) MS has a PR department that spins bugs as "issues" and tries to dampen criticism of security. In the open source world, people generally call "bugs" "bugs" (and frequently wishlist items "bugs", which would drive companies with marketers bananas).
e) Many previous Microsoft security holes just wouldn't happen in the *IX world because of the more security-oriented culture (note that I suspect that Microsoft is improving here). MSIE and Outlook grant a lot of power to remote websites to cause execution, to modify bookmark lists, and the like. Windows NT infamously shipped with a blank Administrator password (and no prompt to set one during the install process), all drives shared by default *invisibly* (they were administrative shares, and the only security in place was the fact that Microsoft clients didn't display administrative shares remotely), and automatically reshared drives upon reboot if sharing was turned off on a drive.
f) Microsoft has been known to blame sysadmins for security problems ("Well, yeah, your network was compromised and your data destroyed by the latest virus, but you didn't firewall our systems, and we released a patch a week ago which you should have deployed.") *IX boxes was designed to sit on a network and be fully accessable, and "firewalling to fix implementation flaws" is not an interesting approach to most *IX admins. Plus, most open source contributors *are* sysadmins to some extent.
Want to do some *real* security criticisms of Linux? How about the following:
* Red Hat was trying to set a new golden security standard for Linux by adding SELinux *by default* starting in Fedora Core 2. This would have allowed giving limited access to things to processes (a sore Linux lack), helped make software SELinux-compatible, and paved the road for other distro vendors. Red Hat, after two test releases, finally just backed down on including SELinux enabled by default in FC2, saying that it just caused too many problems at the moment. This represents a loss of a year at least in moving to a much more powerful and secure security system.
* Stack overflow protection mechanisms are still not standard in the Linux world. The only distro vendor that I know of that definitely includes such a patch enabled by default currently is Red Hat with exec-shield. In contrast, *Microsoft* just added stack execution blocking to Windows.
* Filesystem ACL support in Linux today sucks. A lot. A software author cannot rely on filesystem ACLs being present (since they are not by default on most Linux boxes) -- just old-style *IX permissions. One can improvise to get *some* of the ACL functionality by cleverly nesting directories and adding users to extra groups for each directory in question, but most Linux boxes *still* have a 32 group-per-user limit. The *IX permission scheme is simple, fast, and easy-to-audit. However, it is lacking for many users -- there are a lot of sysadmins out there who'd like to be able to say "Anyone in Development can read or write this directory, Mary and all of the Marketing gro
Why does America have so much control over the 'net these days? It's not a research experiment anymore. It is a way of life. Gotta let it grow even if it's not in all the best interests...
Can't agree with you. Anyone can set up whatever networks they want and make them routable onto the Internet without too much crap coming from the US government. I'm guessing that ICANN/IANA is probably more US-oriented, but I'm dubious as to how many problems that's caused.
IP allocation is clearly US-biased, but that's a legacy problem, and folks that don't like it should be moving to IPv6, which makes life better for everyone involved.
A lot of protocols use English as commands, and RFCs are written in English. I think that's just because English is the most common language of techies than because of any deliberate influence.
Where did they come up with these passwords? It looks like the result of a run someone did a tech university back in the day with crack or sniffing or something. I mean, while I agree that many of the passwords listed there were weak, I'm dubious about how common they are, unless g6PJ, 3ep5w2u, or I5rDv2b2JjA8Mm are particularly common egregious offenders.
Honestly, this is filler as far as content quality goes.
While these are probably in people's heads, they shouldn't be.
1. It's built by "evil hackers"
I think a number of people might be appalled to learn that a lot of software is contracted and subcontracted for, licensed from other companies, and so forth. Buying from a *closed* source company just makes it easier for malicious software to slip by -- remember that Borland Interbase had a back door that was never publically disclosed and fixed until the database was open sourced. A reputable software project has the maintainer review patches.
2. Since it's free, Mr CIO can't farm it out as a big money contract to one of his mates, or one-up that and hire them all under his wings as 'consultants'.
Yeah, right. IBM is a great counterexample of someone who will be more than happy to sell you exorbantly expensive services along with that copy of Linux. Red Hat sells a $1500 copy of Red Hat (their Advanced Enterprise Server something-or-other). If you want to blow money on Linux to companies based in your provience, it's most doable.
3. Since it's free, there is no one being paid to answer the phone when stuff breaks.
There isn't *now*. "Hello, Microsoft? I found this bug in Windows? What's that? You appreciate the heads-up and you'll have it fixed and a patch out to me in two weeks? Thanks!" A pipe dream. I've generally seen better communication (i.e. not having to dredge through a layer of salespeople) with open-source folks. You can get folks who will be happy to sell you service contracts on your software if that's what you want.
Not true. You have to pay monthly for the electricity to keep that hardrive spinning and your NIC pumping bits, and the computer clocking along that supports both. You need to pay monthly for the cooling, and either rent or property taxes on the building they are in. There's also the ongoing cost of replacement hardware, and the ongoing cost of the personnel who supervise and perform these functions. It does not matter if you do it yourself, or pay a colo to do it, but you will pay it.
Okay, I did over-simplify, but the variables involved are still effectively the same. Constant cost (where the variable is the number of games being sold) for most of these, and only a small cost per-game sold. There is no cost per-game-estimated-to-be-sold. Nobody will stock copies of Curse of the Azure Bonds, because it's an ancient DOS game, and costs them in warehousing. If they keep Curse of the Azure Bonds available, though, as one of many titles they sell, they have very little storage cost. They need to keep one copy on a server, not 5,000 units in a warehouse getting dusty in case someone wants to buy one. So that small number of people who say "Gee, I'd like to play Curse of the Azure Bonds" can still be served.
Electronic storage and distribution is niether free nor a one-time cost.
But it there is no cost (well, negligable to the point of not being an issue) associated with stocking something. Any cost caused is associated with either actual sales (which are presumably priced at such a point that they are profitable), or is effectively constant per-store -- the building, the servers, the air conditioning. Adding another drive doesn't cost much more.
Storing credit card info? A non-trival security problem, not just from the outside, but the inside as well.
Yes, but that's an issue that any Web-based retailer (even for physical products) already has to pay for in the form of their sales database.
This sounds like a recipe for customer service nightmares.
[shrug] Then another private identifier (like the infamous mother's maiden name that web merchants like to use with accounts these days) plus a street address. Companies provide customer service on products all the time -- systems to deal with matching a customer to an older purchase are presumably in place. I mean, I can call up a company right now and probably impersonate someone (like call up the cable company and pretend to be someone and get their cable shut off), but in practice it isn't a really huge problem.
A small fee for transfer costs? That's a *real* good way to piss off your customers.
I don't see why -- even if a physical product failed and a web retailer will replace it, I generally have to pay shipping back. (The main point of such a fee would be allowing the requirement of current credit card data, which would make it easier to detect fraud -- if five requests from different people come in on a single purchase, something is quite wrong.)
The problem is that your scheme partially solves one problem (patches) while introducing a whole host of new ones. The issue isn't as simple as it's often painted.
[shrug] I'll buy that -- any time you try out a new scheme, you're going to run into lots of issues that you didn't expect. However, my interest is primarily in solving issues with retailers being limited in what they can stock, and in reducing distribution costs. A number of the things I listed were just nice perks of the format.
I don't think that e-distribution of software is infeasible.
It has been tried before (not just as shareware, but as retailers selling electronic copies of software). I haven't seen anyone that's done too well, but there are major changes today from earlier:
* More people have broadband Internet connections. Just three years ago, that was a huge limiting factor.
* More software can rely on people having always-on Internet connections. This changes copy pr
I've pointed out before that with Apple's move to *IX, it's "Microsoft versus *IX" -- everyone else uses *IX.
With such a move, almost all the major OSes except Microsoft's would also be open-source.
I'm kind of amazed that Sun would take such a stance, but I guess they need to do what they can to retain market share...but still, how are they going to make money from Solaris then? Make most of Solaris GPL but retain some of it? Go totally into services?
It'd be an awfully big jump, with a lot of risk involved...
Also, I dunno whether I'd be comfortable as Sun trusting the FSF to have a huge amount of power over my IP. They didn't get the benefit of the GPL in making the software, but they would have the risk...I dunno.
This is a good point, but I can think of at least some prescedent. The product *is* different in that you get a CD/box/paper manual, etc, and I think you *could* have it cost less.
The best parallel I can think of is old personal computer systems that sold in "kit" form, like the Timex Sinclair. Admittedly, you'd still get them through the same channels...but you could buy a different product that replaced the first for a lower price -- but many people still purchased preassembled systems, despite the higher price, because they wanted everything done for them.
Many Linux distributors today currently provide something similar -- a *free* set of CD images, with the only removed features being a box, pressed CDs, any paper documentation, and installation support, and they seem to have convinced many retailers to carry their products, so I believe that there are retailers that are willing to work with such a constraint. That is also why I gave the example of a web-based retailer -- I buy almost all my games from online merchants, and for an online merchant, it's just as easy to provide downloads...and they get a sale either way, but they have lower distribution costs for a download.
Not true. You still need the servers and people to maintain them, and the bandwidth to transfer them across. True, it's not as expensive as a traditional warehouse, but it's not free, not by a long shot.
There is some cost; my point is that that is effectively either constant or per-copy-sold. Warehousing is an issue with physical because you have to predict how well something will sell and then produce that many units...and then it costs you money to have a bunch of units sitting around in a warehouse. Pain in the rear end for retailers. So, maybe I think that Max Payne III is going to sell more copies than any other game in existence, and I produce and warehouse many, many units, and it flops. That costs money. With electronic distribution...I only need to pay once for the hard drive space for the game (negligable, even if you have servers scattered around the world) and for bandwidth for each copy sold.
And the headache of dealing with customers who stored their purchse information on the same (now crashed) HD that formerly held the game. And the headache of multiple users that use the same purchase code... (Not an issue for MMO's that charge a fee, or shareware which assumes honesty, but a problem for other games.)
Yeah, but realistically, if you're asking for credit card or some other information that people aren't going to want to hand around, it shouldn't be an issue. And you can always say "only N re-downloads of the software", etc. Oh, and maybe charge a small fee to cover any re-transfer costs.
Which ignores the problem of the users that downloaded the software version that contains V1.011 of Rocket Launcher Rebels. You'll always have someone who'll need to patch. (And lets face reality here, increasingly PC games automagically locate and DL pathches.)
Yeah, I suppose so -- autopatching is a good point. I still think that *partially* solving the problem is better than not solving it, though.
Re:this is like shooting fish in a barrel
on
Robosaurus
·
· Score: 1
It doesn't even have to be via P2P -- it's quite possible to let users download an installer to their hard drive from a website that takes a payment.
But unless the publisher stipulates otherwise (and I'd imagine that there's probably a publisher that's willing to work with a developer on this), there's no reason that a game cannot be sold both through traditional channels and online channels.
Distribution costs for a gig of data are a couple of cents. That's a lot cheaper than buying a box and CD, and many people are happy to just buy the software (and don't give a damn about a pressed CD). So provide both, and pass on the distribution savings to the customer.
I suspect that some webmerchant retailers might be happy to provide both download services and physical boxe sales. I'd guess that in the Linux world, Tux Games probably would be willing to try something like that.
Benefits of online distribution:
* Small sales can be made, so budget/older titles can be available.
* Warehousing costs do not exist, so titles that are unlikely to sell well can be made available, and there is no reason for something to go "out of print" (it irritates me to no end when a book goes out of print). That oddball game title that did well in Japan but was unlikely to do well in the US can, for the cost of no more than the translation fee, be sold in the US.
* A reliable backup of your game. Ever lose a CD? It'd be easy for a retailer to verify your purchase information and provide additional downloads of the game.
* Patches included in copies as soon as they are finished. Normally, a pressed run of CDs is locked in, with all the bugs that might be found. Users must go online, locate a patch (usually on a publisher's or developer's website -- and too intimidating for many users) and apply it. If Boomstick Development comes out with a fix for their rocket launcher and releases v1.09 of Rocket Launcher Rebels, they can have their retailer automatically provide an updated release, rather than forcing users to obtain and apply the patch.
* Broader distribution area. It's easier to ship electronic copies of something than it is physical copies -- maybe you can't ship boxed software to a Mongolian plain easily or cheaply, but you can transfer it via satellite downlink.
* Speed of purchase. I generally can't get an obscure game without combing the web and ordering something FedEx. If I download a game and install it, I can have it as soon as my Internet connection brings it down.
* Risk. The more distribution that's done electronically, the lower the financial risk the publisher has to assume for deciding to committing to publish a game. That means they don't have to demand such a large chunk of money from the developer.
There are a couple of issues.
* Piracy is an obvious one, but really, there aren't many more barriers to ripping and copying a physical CD than there are to transferring a file -- in general, any form of remotely effecitve protection is going to take place in the form of checking in the game software itself.
* Consumer Appeal. I'm not sure how people will react to buying something that isn't physical (though I can think of some partial solutions to th eproblem). People do certainly purchase services all the time.
Re:Capture and Sell them!
on
Koalas Gone Wild
·
· Score: 4, Funny
They sleep 14 hours a day, they are grouchy, irritable and they stink.
They have two defense mechanisms: Peeing on things and exceedingly long, tough claws.
They view many things, including being held as threatening and they are not afraid to use both defense mechanisms on short notice.
There are a band of lunatics that enjoy being subjected to this kind of behavior. We call them "cat lovers".
Other places have taken similar steps: Lousiana has a problem with damage done by nutria (think sorta like a muskrat) that was once prized as a furbearer but now is regarded as an invasive species and as a nuisance. The solution provided by the website: "The Coastwide Nutria Control Program, paired with the promotion of nutria meat as a high-protein, low-fat food source, is the main hope for Louisiana's coast." Yum.
Good job, PETA. "Don't wear fur, don't wear fur, don't...damn, we're covered in muskrats."
Oh, and before you ask, we can't really ship them anywhere else. Unless you know somewhere that's able to accomodate 20,000 koalas on short notice, and have a few million dollars to implement the move.
Japan is nuts about koalas. I doubt the climate works, though.
What eats koalas on the mainland? What about introducing a couple of those predators?
Err...I just read the article, and it's not all that cutting, really. It's just saying that "the GIMP doesn't yet have the interface of a MacOS X applications", "the display is slow" (dunno about that, but I'd be curious as to how X11 performs on OS X), and there aren't previews.
I ran into the same irritation with a lack of standardized preview code, and already started poking at producing a standard preview interface -- but stopped because of the 2.0 freeze. When I get time, if other folks haven't started again, I'll be back at it again.
As for a Mac OS X interface -- the GIMP looks like a regular ol' app on Linux. If a Mac OS X guy wants to step forward and add an interface on GIMP that conforms to Mac OS X conventions, that's certainly reasonable. My guess is that's it's just a lack of open source developers on Mac OS X showing up.
I haven't used the GIMP on OS X, and I'm not sure why he considered it sluggish, though I suppose it could be.
You know what I think would be an excellent RPG? Playing the role of a team of Vatican agents, investigating a series of alleged miracles; maybe it could be traced back to a fictional coverup or something. I haven't really fleshed out the idea too well just yet. But it'd be an interesting concept, I think.
Oh, I agree absolutely. I use Mozilla Firebird with privoxy, and I think that anyone that uses the Web should really do the same -- no more flashing ads and popups zinging around.
However, what I have a problem with is advocacy of a legal solution rather than a technical solution. Yes, sometimes you're stuck with a legal approach, but this is a problem for which there is a good technical fix.
I don't know the specifics either -- I ran into this when trying to track down why valgrind suddenly wasn't packaged by any of the big third party Fedora RPM packagers.
If this *does* get resolved so that valgrind can go into Fedora Core 2, I have to say that that would be *awesom*.
The problem I have is that medical development today is impacted by this. Robotic surgery, for instance, is largely at a standstill because of consumer concerns based partly on fallout from things like the Therac-25. I know one person working on robot-assisted surgery -- he was limited to producing an exoskeleton-like arm cage that did nothing but exert passive force -- braking only -- to keep surgeons from slipping and slicing something. Consumers were too afraid from having a computer wielding a knife near their heart.
[shrug] That doesn't mean that specs are a panacea for bugfree software, and I recognize that there is a cost to use of specs. It's just that I get marvelously irritated when anyone considers remotely cutting corners in medical software, because of the damage that a few cut corners in the past have caused to the medical technology industry today.
I realize that you're just being honest, and that people that provide an impression of perfection when doing medical software are probably just engaging in a bit of marketing.
Should software products be required, in end-user-understandable language, to provide a full description of all the information they disclose? That seems like the most straightforward way to legislate what you're asking for.
Now think about the practical impact of such a system.
First, is every open source programmer going to suddenly be faced with writing a big document to be allowed to let users in the United States use his software? And update that document for each release? Good technical writing isn't cheap.
Second, are these rules going to limit introduction of new systems? Frankly, InstallShield is a disaster from a security and reliability standpoint. If there are a collection of laws made relating to InstallShield, what happens when someone introduces a better replacement for InstallShield, and there's a law on the books that says "Programs shall add themselves to the Add/Remove Programs list".
Third, are these laws going to pose a pain in the ass for users of Linux and other OSes? If there's a technical problem with Microsoft software (MSIE allows unrequested popups), is it fair to force users to read through an agreement at every site they come to disclosing all the possible ways a popup could come up?
Fourth, is it possible to enforce laws like this? We have some laws now against spam in the US. It hasn't done a damn thing, because it's so easy for a Korean to continue doing the same thing or for spammers to stay untraceable.
Fifth, why should I have to have more laws on the books because OSes fail to compartmentalize software well enough or fail to allow a user to see what's going on with his system? Linux not allowing/proc to be restricted out-of-box or Windows allowing processes to hide themselves from the process list is a technical problem, not a legal one.
Sixth, why is a legal solution necessary? It seems to me that an organization that certifies software (as the BBB does to certify businesses) would provide most of the same benefits, but without the potential drawbacks.
Government regulation to solve a problem that can be solved with a technical solution is no more desireable.
Blame Microsoft for poor security policy and placing a low priority on keeping the user in control of their system, not on the FTC failing to make a law.
Almost all other OS vendors have placed a high degree of emphasis on keeping the user in control of their system. Apple forbid software following the HIG to do anything based only on cursor movement, for instance -- the idea is that the user should never feel that he is not in control of what's going on. ActiveX and unblocked popups are an artifact of Internet Explorer. The fact that IE provides a huge loophole for malicious applications to use to slip through firewalls is due to the fact that MS considered the political benefits of them to insinuating MSIE throughout their OS outweighed the benefits to the user of having a secure system where they could easily monitor and control what was going out. MS has no problem with broadcasting the computer name, logged-on-user's name and such information to the world at large via the Windows networking system MS was less worried about execution of active content in emails than about the security implications to users of doing so -- the idea was that "security is hard to sell to a user, so we won't worry about it." The few times that they have "sold security", it's frequently a load of bullshit that has little to do with real security, like driver signing or DRM. Windows suffers from fundamental API security problems like the Shatter attacks. Currently, it may actually be that market pressures are making them honestly wish that they had done something different, but they have a thoroughly worm-eaten structure from a security standpoint now -- many of their decisions cannot be taken back, and many others would be phenomenally expensive to do so. Their lack of concern for security has made many third-party vendors in turn feel that application security is unimportant, and exacerbated the problem. I've heard some great horror stories about internal Microsoft development security practices. If the OS vendor does not provide a solid, secure foundation and set a good example themselves, nobody else does. Windows just does not have a culture of caring about security, and it has come back and firmly bitten some asses (to the great satisfaction of those of us who have been vehemently arguing that Microsoft should place security more highly and limit trust of remote websites to control the local machine all along).
Yeah, right. I can just see what things would be like today if federal officials had been doing what you're proposing for a while now.
"All software products must clearly disclose on their box or in a startup agreement in black text of no less than half a centimeter high whether or not they use EMS or not."
Federal law has a hard time keeping up with technology. I can only imagine the impact of product-specific laws.
There are good *technical* solutions to your problem. The problem is that Windows uses a mind-bogglingly poor system for installation of software. Mac OS uses a "drag your folder to where you want it, delete it when you don't want it" approach to software installation and uninstallation. RPM-based Linux distributions use RPMs for everything, which always contain a list of the files being installed (and one where you can check where config files are, when software was installed and built, what software other things depend upon, etc). It's quite technically possible to have the OS monitor what an application does during installation and roll back everything when done -- Microsoft has chosen not to do so. This is a technical flaw on their part, not something that requires legal intervention that impacts Linux users and everyone else in the world.
Slashdot Mirror
You are right. Something is decidedly wrong on your system. It takes me, IIRC, under a second to go from "bootloader screen" to "kernel spitting out init data". It is definitely not twenty seconds.
Now, the time spent sitting in init scripts when a desktop could be brought up much faster and initscript loading continued in the background is an arguable issue...
If you dont believe my security statement, just wander on over to securitytracker.com - there are more discovered flaws in the recent past with Linux than with Windows.
a) Despite the increased amount of bundling Microsoft's done over the years, a "Linux distribution flaw" is still awfully different from a "Windows security flaw". A Linux distribution is composed of many, many more lines of code and pieces of software than Windows. If you want to include security problems with Open Office, it's only reasonable to include security problems with MS Office.
b) Local exploits attract attention on Linux. A lot of "exploits" in Linux are local attacks. Local security on a Windows box is pretty much a lost cause.
c) When Microsoft discovers a security problem and fixes it internally, they don't say "fixes a security hole in...". They just bundle it with some other set of fixes and stay quiet. You won't hear about it.
d) MS has a PR department that spins bugs as "issues" and tries to dampen criticism of security. In the open source world, people generally call "bugs" "bugs" (and frequently wishlist items "bugs", which would drive companies with marketers bananas).
e) Many previous Microsoft security holes just wouldn't happen in the *IX world because of the more security-oriented culture (note that I suspect that Microsoft is improving here). MSIE and Outlook grant a lot of power to remote websites to cause execution, to modify bookmark lists, and the like. Windows NT infamously shipped with a blank Administrator password (and no prompt to set one during the install process), all drives shared by default *invisibly* (they were administrative shares, and the only security in place was the fact that Microsoft clients didn't display administrative shares remotely), and automatically reshared drives upon reboot if sharing was turned off on a drive.
f) Microsoft has been known to blame sysadmins for security problems ("Well, yeah, your network was compromised and your data destroyed by the latest virus, but you didn't firewall our systems, and we released a patch a week ago which you should have deployed.") *IX boxes was designed to sit on a network and be fully accessable, and "firewalling to fix implementation flaws" is not an interesting approach to most *IX admins. Plus, most open source contributors *are* sysadmins to some extent.
Want to do some *real* security criticisms of Linux? How about the following:
* Red Hat was trying to set a new golden security standard for Linux by adding SELinux *by default* starting in Fedora Core 2. This would have allowed giving limited access to things to processes (a sore Linux lack), helped make software SELinux-compatible, and paved the road for other distro vendors. Red Hat, after two test releases, finally just backed down on including SELinux enabled by default in FC2, saying that it just caused too many problems at the moment. This represents a loss of a year at least in moving to a much more powerful and secure security system.
* Stack overflow protection mechanisms are still not standard in the Linux world. The only distro vendor that I know of that definitely includes such a patch enabled by default currently is Red Hat with exec-shield. In contrast, *Microsoft* just added stack execution blocking to Windows.
* Filesystem ACL support in Linux today sucks. A lot. A software author cannot rely on filesystem ACLs being present (since they are not by default on most Linux boxes) -- just old-style *IX permissions. One can improvise to get *some* of the ACL functionality by cleverly nesting directories and adding users to extra groups for each directory in question, but most Linux boxes *still* have a 32 group-per-user limit. The *IX permission scheme is simple, fast, and easy-to-audit. However, it is lacking for many users -- there are a lot of sysadmins out there who'd like to be able to say "Anyone in Development can read or write this directory, Mary and all of the Marketing gro
Why does America have so much control over the 'net these days? It's not a research experiment anymore. It is a way of life. Gotta let it grow even if it's not in all the best interests...
Can't agree with you. Anyone can set up whatever networks they want and make them routable onto the Internet without too much crap coming from the US government. I'm guessing that ICANN/IANA is probably more US-oriented, but I'm dubious as to how many problems that's caused.
IP allocation is clearly US-biased, but that's a legacy problem, and folks that don't like it should be moving to IPv6, which makes life better for everyone involved.
A lot of protocols use English as commands, and RFCs are written in English. I think that's just because English is the most common language of techies than because of any deliberate influence.
Where did they come up with these passwords? It looks like the result of a run someone did a tech university back in the day with crack or sniffing or something. I mean, while I agree that many of the passwords listed there were weak, I'm dubious about how common they are, unless g6PJ, 3ep5w2u, or I5rDv2b2JjA8Mm are particularly common egregious offenders.
Honestly, this is filler as far as content quality goes.
Koalas are the only animal that doesn't drink water.
There are many animals, including a number of mammals, that do not drink water.
Here's a quick link from Google on one of the examples.
While these are probably in people's heads, they shouldn't be.
1. It's built by "evil hackers"
I think a number of people might be appalled to learn that a lot of software is contracted and subcontracted for, licensed from other companies, and so forth. Buying from a *closed* source company just makes it easier for malicious software to slip by -- remember that Borland Interbase had a back door that was never publically disclosed and fixed until the database was open sourced. A reputable software project has the maintainer review patches.
2. Since it's free, Mr CIO can't farm it out as a big money contract to one of his mates, or one-up that and hire them all under his wings as 'consultants'.
Yeah, right. IBM is a great counterexample of someone who will be more than happy to sell you exorbantly expensive services along with that copy of Linux. Red Hat sells a $1500 copy of Red Hat (their Advanced Enterprise Server something-or-other). If you want to blow money on Linux to companies based in your provience, it's most doable.
3. Since it's free, there is no one being paid to answer the phone when stuff breaks.
There isn't *now*. "Hello, Microsoft? I found this bug in Windows? What's that? You appreciate the heads-up and you'll have it fixed and a patch out to me in two weeks? Thanks!" A pipe dream. I've generally seen better communication (i.e. not having to dredge through a layer of salespeople) with open-source folks. You can get folks who will be happy to sell you service contracts on your software if that's what you want.
Linus, even if a product of Finland, currently resides in the US.
Not true. You have to pay monthly for the electricity to keep that hardrive spinning and your NIC pumping bits, and the computer clocking along that supports both. You need to pay monthly for the cooling, and either rent or property taxes on the building they are in. There's also the ongoing cost of replacement hardware, and the ongoing cost of the personnel who supervise and perform these functions. It does not matter if you do it yourself, or pay a colo to do it, but you will pay it.
Okay, I did over-simplify, but the variables involved are still effectively the same. Constant cost (where the variable is the number of games being sold) for most of these, and only a small cost per-game sold. There is no cost per-game-estimated-to-be-sold. Nobody will stock copies of Curse of the Azure Bonds, because it's an ancient DOS game, and costs them in warehousing. If they keep Curse of the Azure Bonds available, though, as one of many titles they sell, they have very little storage cost. They need to keep one copy on a server, not 5,000 units in a warehouse getting dusty in case someone wants to buy one. So that small number of people who say "Gee, I'd like to play Curse of the Azure Bonds" can still be served.
Electronic storage and distribution is niether free nor a one-time cost.
But it there is no cost (well, negligable to the point of not being an issue) associated with stocking something. Any cost caused is associated with either actual sales (which are presumably priced at such a point that they are profitable), or is effectively constant per-store -- the building, the servers, the air conditioning. Adding another drive doesn't cost much more.
Storing credit card info? A non-trival security problem, not just from the outside, but the inside as well.
Yes, but that's an issue that any Web-based retailer (even for physical products) already has to pay for in the form of their sales database.
This sounds like a recipe for customer service nightmares.
[shrug] Then another private identifier (like the infamous mother's maiden name that web merchants like to use with accounts these days) plus a street address. Companies provide customer service on products all the time -- systems to deal with matching a customer to an older purchase are presumably in place. I mean, I can call up a company right now and probably impersonate someone (like call up the cable company and pretend to be someone and get their cable shut off), but in practice it isn't a really huge problem.
A small fee for transfer costs? That's a *real* good way to piss off your customers.
I don't see why -- even if a physical product failed and a web retailer will replace it, I generally have to pay shipping back. (The main point of such a fee would be allowing the requirement of current credit card data, which would make it easier to detect fraud -- if five requests from different people come in on a single purchase, something is quite wrong.)
The problem is that your scheme partially solves one problem (patches) while introducing a whole host of new ones. The issue isn't as simple as it's often painted.
[shrug] I'll buy that -- any time you try out a new scheme, you're going to run into lots of issues that you didn't expect. However, my interest is primarily in solving issues with retailers being limited in what they can stock, and in reducing distribution costs. A number of the things I listed were just nice perks of the format.
I don't think that e-distribution of software is infeasible.
It has been tried before (not just as shareware, but as retailers selling electronic copies of software). I haven't seen anyone that's done too well, but there are major changes today from earlier:
* More people have broadband Internet connections. Just three years ago, that was a huge limiting factor.
* More software can rely on people having always-on Internet connections. This changes copy pr
Wow.
I've pointed out before that with Apple's move to *IX, it's "Microsoft versus *IX" -- everyone else uses *IX.
With such a move, almost all the major OSes except Microsoft's would also be open-source.
I'm kind of amazed that Sun would take such a stance, but I guess they need to do what they can to retain market share...but still, how are they going to make money from Solaris then? Make most of Solaris GPL but retain some of it? Go totally into services?
It'd be an awfully big jump, with a lot of risk involved...
Also, I dunno whether I'd be comfortable as Sun trusting the FSF to have a huge amount of power over my IP. They didn't get the benefit of the GPL in making the software, but they would have the risk...I dunno.
This is a good point, but I can think of at least some prescedent. The product *is* different in that you get a CD/box/paper manual, etc, and I think you *could* have it cost less.
The best parallel I can think of is old personal computer systems that sold in "kit" form, like the Timex Sinclair. Admittedly, you'd still get them through the same channels...but you could buy a different product that replaced the first for a lower price -- but many people still purchased preassembled systems, despite the higher price, because they wanted everything done for them.
Many Linux distributors today currently provide something similar -- a *free* set of CD images, with the only removed features being a box, pressed CDs, any paper documentation, and installation support, and they seem to have convinced many retailers to carry their products, so I believe that there are retailers that are willing to work with such a constraint. That is also why I gave the example of a web-based retailer -- I buy almost all my games from online merchants, and for an online merchant, it's just as easy to provide downloads...and they get a sale either way, but they have lower distribution costs for a download.
Not true. You still need the servers and people to maintain them, and the bandwidth to transfer them across. True, it's not as expensive as a traditional warehouse, but it's not free, not by a long shot.
There is some cost; my point is that that is effectively either constant or per-copy-sold. Warehousing is an issue with physical because you have to predict how well something will sell and then produce that many units...and then it costs you money to have a bunch of units sitting around in a warehouse. Pain in the rear end for retailers. So, maybe I think that Max Payne III is going to sell more copies than any other game in existence, and I produce and warehouse many, many units, and it flops. That costs money. With electronic distribution...I only need to pay once for the hard drive space for the game (negligable, even if you have servers scattered around the world) and for bandwidth for each copy sold.
And the headache of dealing with customers who stored their purchse information on the same (now crashed) HD that formerly held the game. And the headache of multiple users that use the same purchase code... (Not an issue for MMO's that charge a fee, or shareware which assumes honesty, but a problem for other games.)
Yeah, but realistically, if you're asking for credit card or some other information that people aren't going to want to hand around, it shouldn't be an issue. And you can always say "only N re-downloads of the software", etc. Oh, and maybe charge a small fee to cover any re-transfer costs.
Which ignores the problem of the users that downloaded the software version that contains V1.011 of Rocket Launcher Rebels. You'll always have someone who'll need to patch. (And lets face reality here, increasingly PC games automagically locate and DL pathches.)
Yeah, I suppose so -- autopatching is a good point. I still think that *partially* solving the problem is better than not solving it, though.
The ones that don't run Linux...yet!
It doesn't even have to be via P2P -- it's quite possible to let users download an installer to their hard drive from a website that takes a payment.
But unless the publisher stipulates otherwise (and I'd imagine that there's probably a publisher that's willing to work with a developer on this), there's no reason that a game cannot be sold both through traditional channels and online channels.
Distribution costs for a gig of data are a couple of cents. That's a lot cheaper than buying a box and CD, and many people are happy to just buy the software (and don't give a damn about a pressed CD). So provide both, and pass on the distribution savings to the customer.
I suspect that some webmerchant retailers might be happy to provide both download services and physical boxe sales. I'd guess that in the Linux world, Tux Games probably would be willing to try something like that.
Benefits of online distribution:
* Small sales can be made, so budget/older titles can be available.
* Warehousing costs do not exist, so titles that are unlikely to sell well can be made available, and there is no reason for something to go "out of print" (it irritates me to no end when a book goes out of print). That oddball game title that did well in Japan but was unlikely to do well in the US can, for the cost of no more than the translation fee, be sold in the US.
* A reliable backup of your game. Ever lose a CD? It'd be easy for a retailer to verify your purchase information and provide additional downloads of the game.
* Patches included in copies as soon as they are finished. Normally, a pressed run of CDs is locked in, with all the bugs that might be found. Users must go online, locate a patch (usually on a publisher's or developer's website -- and too intimidating for many users) and apply it. If Boomstick Development comes out with a fix for their rocket launcher and releases v1.09 of Rocket Launcher Rebels, they can have their retailer automatically provide an updated release, rather than forcing users to obtain and apply the patch.
* Broader distribution area. It's easier to ship electronic copies of something than it is physical copies -- maybe you can't ship boxed software to a Mongolian plain easily or cheaply, but you can transfer it via satellite downlink.
* Speed of purchase. I generally can't get an obscure game without combing the web and ordering something FedEx. If I download a game and install it, I can have it as soon as my Internet connection brings it down.
* Risk. The more distribution that's done electronically, the lower the financial risk the publisher has to assume for deciding to committing to publish a game. That means they don't have to demand such a large chunk of money from the developer.
There are a couple of issues.
* Piracy is an obvious one, but really, there aren't many more barriers to ripping and copying a physical CD than there are to transferring a file -- in general, any form of remotely effecitve protection is going to take place in the form of checking in the game software itself.
* Consumer Appeal. I'm not sure how people will react to buying something that isn't physical (though I can think of some partial solutions to th eproblem). People do certainly purchase services all the time.
They sleep 14 hours a day, they are grouchy, irritable and they stink.
They have two defense mechanisms: Peeing on things and exceedingly long, tough claws.
They view many things, including being held as threatening and they are not afraid to use both defense mechanisms on short notice.
There are a band of lunatics that enjoy being subjected to this kind of behavior. We call them "cat lovers".
Other places have taken similar steps: Lousiana has a problem with damage done by nutria (think sorta like a muskrat) that was once prized as a furbearer but now is regarded as an invasive species and as a nuisance. The solution provided by the website: "The Coastwide Nutria Control Program, paired with the promotion of nutria meat as a high-protein, low-fat food source, is the main hope for Louisiana's coast." Yum.
Good job, PETA. "Don't wear fur, don't wear fur, don't...damn, we're covered in muskrats."
Oh, and before you ask, we can't really ship them anywhere else. Unless you know somewhere that's able to accomodate 20,000 koalas on short notice, and have a few million dollars to implement the move.
Japan is nuts about koalas. I doubt the climate works, though.
What eats koalas on the mainland? What about introducing a couple of those predators?
Err...I just read the article, and it's not all that cutting, really. It's just saying that "the GIMP doesn't yet have the interface of a MacOS X applications", "the display is slow" (dunno about that, but I'd be curious as to how X11 performs on OS X), and there aren't previews.
I ran into the same irritation with a lack of standardized preview code, and already started poking at producing a standard preview interface -- but stopped because of the 2.0 freeze. When I get time, if other folks haven't started again, I'll be back at it again.
As for a Mac OS X interface -- the GIMP looks like a regular ol' app on Linux. If a Mac OS X guy wants to step forward and add an interface on GIMP that conforms to Mac OS X conventions, that's certainly reasonable. My guess is that's it's just a lack of open source developers on Mac OS X showing up.
I haven't used the GIMP on OS X, and I'm not sure why he considered it sluggish, though I suppose it could be.
Here's a quick link on the rather convoluted history of the Pledge.
You know what I think would be an excellent RPG? Playing the role of a team of Vatican agents, investigating a series of alleged miracles; maybe it could be traced back to a fictional coverup or something. I haven't really fleshed out the idea too well just yet. But it'd be an interesting concept, I think.
:-)
I kinda do too, but...
"Stigmata: The Movie: The Game"
Oh, I agree absolutely. I use Mozilla Firebird with privoxy, and I think that anyone that uses the Web should really do the same -- no more flashing ads and popups zinging around.
However, what I have a problem with is advocacy of a legal solution rather than a technical solution. Yes, sometimes you're stuck with a legal approach, but this is a problem for which there is a good technical fix.
I don't know the specifics either -- I ran into this when trying to track down why valgrind suddenly wasn't packaged by any of the big third party Fedora RPM packagers.
If this *does* get resolved so that valgrind can go into Fedora Core 2, I have to say that that would be *awesom*.
The problem I have is that medical development today is impacted by this. Robotic surgery, for instance, is largely at a standstill because of consumer concerns based partly on fallout from things like the Therac-25. I know one person working on robot-assisted surgery -- he was limited to producing an exoskeleton-like arm cage that did nothing but exert passive force -- braking only -- to keep surgeons from slipping and slicing something. Consumers were too afraid from having a computer wielding a knife near their heart.
[shrug] That doesn't mean that specs are a panacea for bugfree software, and I recognize that there is a cost to use of specs. It's just that I get marvelously irritated when anyone considers remotely cutting corners in medical software, because of the damage that a few cut corners in the past have caused to the medical technology industry today.
I realize that you're just being honest, and that people that provide an impression of perfection when doing medical software are probably just engaging in a bit of marketing.
Heave the "baby" out with the bathwater.
/proc to be restricted out-of-box or Windows allowing processes to hide themselves from the process list is a technical problem, not a legal one.
Should software products be required, in end-user-understandable language, to provide a full description of all the information they disclose? That seems like the most straightforward way to legislate what you're asking for.
Now think about the practical impact of such a system.
First, is every open source programmer going to suddenly be faced with writing a big document to be allowed to let users in the United States use his software? And update that document for each release? Good technical writing isn't cheap.
Second, are these rules going to limit introduction of new systems? Frankly, InstallShield is a disaster from a security and reliability standpoint. If there are a collection of laws made relating to InstallShield, what happens when someone introduces a better replacement for InstallShield, and there's a law on the books that says "Programs shall add themselves to the Add/Remove Programs list".
Third, are these laws going to pose a pain in the ass for users of Linux and other OSes? If there's a technical problem with Microsoft software (MSIE allows unrequested popups), is it fair to force users to read through an agreement at every site they come to disclosing all the possible ways a popup could come up?
Fourth, is it possible to enforce laws like this? We have some laws now against spam in the US. It hasn't done a damn thing, because it's so easy for a Korean to continue doing the same thing or for spammers to stay untraceable.
Fifth, why should I have to have more laws on the books because OSes fail to compartmentalize software well enough or fail to allow a user to see what's going on with his system? Linux not allowing
Sixth, why is a legal solution necessary? It seems to me that an organization that certifies software (as the BBB does to certify businesses) would provide most of the same benefits, but without the potential drawbacks.
Government regulation to solve a problem that can be solved with a technical solution is no more desireable.
Blame Microsoft for poor security policy and placing a low priority on keeping the user in control of their system, not on the FTC failing to make a law.
Almost all other OS vendors have placed a high degree of emphasis on keeping the user in control of their system. Apple forbid software following the HIG to do anything based only on cursor movement, for instance -- the idea is that the user should never feel that he is not in control of what's going on. ActiveX and unblocked popups are an artifact of Internet Explorer. The fact that IE provides a huge loophole for malicious applications to use to slip through firewalls is due to the fact that MS considered the political benefits of them to insinuating MSIE throughout their OS outweighed the benefits to the user of having a secure system where they could easily monitor and control what was going out. MS has no problem with broadcasting the computer name, logged-on-user's name and such information to the world at large via the Windows networking system MS was less worried about execution of active content in emails than about the security implications to users of doing so -- the idea was that "security is hard to sell to a user, so we won't worry about it." The few times that they have "sold security", it's frequently a load of bullshit that has little to do with real security, like driver signing or DRM. Windows suffers from fundamental API security problems like the Shatter attacks. Currently, it may actually be that market pressures are making them honestly wish that they had done something different, but they have a thoroughly worm-eaten structure from a security standpoint now -- many of their decisions cannot be taken back, and many others would be phenomenally expensive to do so. Their lack of concern for security has made many third-party vendors in turn feel that application security is unimportant, and exacerbated the problem. I've heard some great horror stories about internal Microsoft development security practices. If the OS vendor does not provide a solid, secure foundation and set a good example themselves, nobody else does. Windows just does not have a culture of caring about security, and it has come back and firmly bitten some asses (to the great satisfaction of those of us who have been vehemently arguing that Microsoft should place security more highly and limit trust of remote websites to control the local machine all along).
Yeah, right. I can just see what things would be like today if federal officials had been doing what you're proposing for a while now.
"All software products must clearly disclose on their box or in a startup agreement in black text of no less than half a centimeter high whether or not they use EMS or not."
Federal law has a hard time keeping up with technology. I can only imagine the impact of product-specific laws.
There are good *technical* solutions to your problem. The problem is that Windows uses a mind-bogglingly poor system for installation of software. Mac OS uses a "drag your folder to where you want it, delete it when you don't want it" approach to software installation and uninstallation. RPM-based Linux distributions use RPMs for everything, which always contain a list of the files being installed (and one where you can check where config files are, when software was installed and built, what software other things depend upon, etc). It's quite technically possible to have the OS monitor what an application does during installation and roll back everything when done -- Microsoft has chosen not to do so. This is a technical flaw on their part, not something that requires legal intervention that impacts Linux users and everyone else in the world.