False. Selective beeding and natural selection both involve the addition (through "natural" radiation, "natural" chemical mutagens, and "natural" retroviruses) of genes that
weren't there before.
Okay, granted. Various natural things do cause mutation and cross-species gene travel and yes, selective breeding (both natural and 'man-made) do bring those to dominance, but that's still different from genetic engineering.
Natural processes are random, which means that most natural mutations either immediately kill the recipient or cause it to be less successful, therefore removing themselves from the gene pool. The chances of a mutation staying in the gene pool are pretty low. This means that the rate at which we get new species is slow, to the point where you almost never see it happen.
In contrast, engineered species are already immediately viable and, because they're useful to people, will stay in the ecosystem for some time. We know the ecosystem can handle normal evolution reasonably well but we have no idea what this sort of rapid change will do.
I'm not opposed to genetic engineering, BTW. It's just that what the big corps are doing right now strikes me as the biological equivalent of a programmer slapping some code together, testing it a couple of times to make sure it doesn't crash and then installing it on the fly-by-wire system of every airliner in the world.
What is the problem with "genetic engineering"? We've been doing it for ages with breeding, as has "nature."
What we traditionally call "genetic engineering" is different from breeding or natural selection because it adds genes that weren't there before while breeding just juggles them about. And the problem with it is that we don't yet understand this sort of DNA manipulation or its consequences well enough to know what will happen when we dump it into the ecosystem. And yet we--or at least Monsanto's customers--are.
I don't agree with the thinking behind a lot of the anti-GM groups but I think that, for the moment anyway, I agree with their goals.
For Example; if you're
running XFree86, find the file(s) "Xaccess" and change the "#*" and "#* CHOOSER BROADCAST" to "!*". This will reject any requests for a logon window (which is
maybe where you get the assumption that the login service is exploitable via the network).
I don't remember how to do it anymore, but I used to have that port closed as well. It seems that X will happily use Unix-domain sockets (i.e. tied to the filesystem and therefore not networked). This means that you can run a Linux workstation with no ports open.
This is all a moot point to me these days since I use a router. However, in my recent dabblings with Fedora, I noticed that it now blocks all but a few ports with iptables and provides a handy clickable interface to select which services you want to offer. I think that qualifies and pretty close to the ideal, although I don't know for sure what's turned on by default, not having done the actual install.
I know I'm feeding the Troll[...]
The trollish "mistake" here is failing to distinguish background processes ("daemons") with network-accessible services. Most of the essential Linux services don't touch the networking system at all.
While I appreciate the sheer perversity of this, it looks a bit fishy to me. Can an E450 handle the bumps, jolts, heat and grime associated with being in a car all of the time? Does it actually use so little power that you can run it off a 12V car battery? Could someone with more hands-on experience with those sorts of beasties please offer an informed opinion?
Could the Slashcode people please add a (-1, Doesn't Get It) moderation option?
This is profoundly stupid because, ta dum, there's no market for it, and no prospect of a market for it.
Yup.
See, this thing is designed to solve the producer's problem rather than the consumer's. The problem, in this case, is that the movie companies aren't making enough money off of rentals. Movie studios get a royalty for each DVD sold, so if you buy a DVD and then rent it out a bunch of times, they get a cut of your initial purchase price but you get all of the rental fees.
This is, in part, why DVDs are so cheap to buy--they're trying to compete with the rental market. Every time you buy a movie instead of renting it, Hollywood gets the royalty instead of the video rental place.
This is just more of the same. If you buy a self-destructing DVD, the effect is the same as a video rental for you (in theory, anyway) but it goes through the same channels as sale DVDs and so Hollywood gets a cut of it.
Will it work? It hasn't so far and my guess is that they won't. From what I've seen so far, it looks to me like they can't make them cheap enough to compete with the video rental places. There seems to be a whole lot of wishful thinking going on here. Still, with that kind of money hanging in front of them, it's very easy to see how the can forget the basic capitalist principal of selling stuff people want to buy.
BTW, the last producer-driven product I can think of was the Cue::Cat. Remember what a well-thought-out success that one was?
When I do Windows development, I do the actual development under
something Unixish and port the result to Windows, typically with the
help of a cross-platform GUI toolkit.
My reasons for not developing under Windows are:
(Non-NT) Windows is abysmal at coping with buggy software. Back
when I developed under Windows 3.1, there were times where I literally
had to reboot my computer each time I ran my program. A couple of
times, the crashes also took out files on my hard disk. NT/XP has
proper memory protection so that's fixed, but I just know they've
screwed up something else just as badly. (Okay, so maybe I'm a little
traumatized.)
The APIs are big, complex and proprietary. To master them would
require a huge time investment and the resulting skills are useless
outside of WindowsLand. Until someone pays me to aquire them, I'm not
going to bother. I have better uses for my time.
I find the tools and documentation to be condescending. I can
sort of see that attitude working on end-users since they don't
usually have the time or inclination to learn how the OS works, but
I'm a programmer--I want to know exactly how it
works, and why.
It's a proprietary platform, which means that my work on it lives
or dies at Microsoft's whim. I'd rather invest my time in something
that I know will still be around in fifty years.
As a user, I'd probably use Windows a little--to play some games
and run the occasional interesting app--if only it weren't so
freaking expensive. I've seen computers for sale that cost less than
just the standalone license for the version of Windows they have
pre-installed.
If I could get a (legal) copy of XP for sixty bucks, I probably
would. But I can't, so I'll just have to keep my money.
What I want to know is where the encryption actually happens. I have a sneaking suspicion that it's all done on the PC side with the included software. Can anyone confirm or deny this?
Has anyone thought the only way to combat this maybe to have the FSF start patenting things?
What the FSF (or some similar organization) should do is start a defensive patent pool. (A patent pool is a collection of patents that may be licensed as a single unit, often held by different entities.) The rules would be:
Anyone can use any patent in the pool to write open-source software.
Any person or company that doesn't hold any software or business-model patents may use any patent in the pool royalty-free.
Any person or company who has contributed all their patents to the pool may use any patent in the pool royalty-free.
The patent pool only covers software implementions, where by "software", we mean a user-installable program on a general-purpose computer. Firmware and a DSP (for example, in a portable MP3 player) doesn't count.
Putting a patent into the pool is irrevokable.
Such a scheme would benefit FOSS developers, small ISVs and any company that uses software patents only defensively. The bigger the pool gets, the more economic sense it makes for a company to join as the potential revenues of their patent portfolios get dwarfed by the money they could save by not having to license pool patents.
The only people it doesn't help against are the true leeches, those folks that obtain patents solely to extort money from actual R&D firms. They don't need to license patents because they don't have an actual product. Of course, they also don't contribute to the arts and it's not inconceivable that the laws may be changed at some point to exclude their business models.
After all, the real makers usually have a lot more money.
The author is probably right about Microsoft hating the web, and
he might even be right in his assertion that Longhorn is their attempt
to replace it with their own thing, but he's wrong in assuming they
even have a chance.
There are two reasons.
Firstly, the web is about small voices. It's not a medium
for selling stuff or issuing press releases (although some people have
made money doing that), it's about ordinary people saying stuff.
Remember how the web used to be, before VCs with their carpet bags
full of money turned great swaths of it into a cheap version of UHF
TV? Doesn't the thought of all the weasels switching to MS-Internet
and going away bring a smile to your face?
Alas, it will not be, for the second reason the Longhorn Strategy
will fail. Because breaking web compatibility means turning away
customers and that's just not good for businesses.
Notice that all the commercial websites still around will work, at
least mostly, on all sorts of browsers? Coincidence? I think not!
Amazon tests their sites using Netscape 1.x! (Or they used to for a
long time anyway--I don't know what their baseline is now.) That way,
they know that their site will work on practically every browser out
there, right out of the box.
Of course, some of the bigger e-business folks may start supporting
Longhorn, but they'll stay compatible with the established standards
because they don't want to lose their customers.
At this point, everyone has W3C-compliant (more or less) browsers
and servers. They can all talk to each other. As soon as someone
switches, they can't talk to the rest anymore and their setup becomes
useless. This is why, for example, nobody has been able to replace
SMTP, despite the whole spam problem.
I predict that we'll remain stuck with HTML, CSS and HTTP for a
long time. The MS extensions will be a kewl technological blip that
nobody will use but, if it's good, may well be lamented by future web
developers as something that could have been.
I'm not usually very good at flamewars, so just pretend I wrote a
lot of incoherent abuse here.
Asserting that developers are dumb because they do not support a
system that was designed to be incompatible is, I would say,
misguided.
If you go back and read my post, you will see that I'm referring
to the behaviour as dumb, not the people. That's a big
distinction. These folks have written a working non-trivial software
package and that requires some smarts. I'm talking about one
particular decision of theirs.
But anyway, let me spell out my reasoning:
Autoconf works around all kinds of different platform-specific
wierdnesses (many of which predate POSIX, BTW) so that my
programs will be widely portable.
PMK tries to be a replacement for autoconf.
Therefore, PMK should also do the same sort of platform-specific
workarounds for me.
PMK does not do this for Cygwin while autoconf does.
Therefore, autoconf solves the portability problem more
effectively than PMK does.
Therefore, PMK is less useful than autoconf.
The PMK team disapproves of that particular part of the problem
(Cygwin has a quirk they don't like) and so refuses to try to solve
it.
Therefore, the PMK team is deliberately refusing to solve
part of the problem they claim they are trying to solve
(i.e. replacing autoconf).
This is dumb.
I mean, not supporting Windows is all well and good (and the sort
of thing I do on occasion) but when your stated goal is to make
software more compatible across platforms, you can't do that without
making yourself a liar.
I could understand it if they'd said, "we're looking for someone
to do a Cygwin port because we can't be bothered." But what they said
was, "Cygwin is broken and we're not going to work around the problem
because they should fix it." This for a tool whose very purpose
is to work around those sorts of problems.
(Note: see my followup to Damien one thread over. I may have
partially misunderstood their position on this, in which case I could
be wrong in my claims of dumb behaviour. But this is how I see things
and my conclusions are derived from that.)
And by the way, I challenge your statement that Windows is the
most popular platform. It may be the most used platform on desktops,
but it's not like every user willingly chose to use it.
Whether or not people like it is irrelevant to my argument.
Windows is the operating system of most of the desktop computers in
the world. If you want to write a program and have it work on the
biggest number of computers possible, you have to make sure it works
under Windows.
As a developer, the best I can do is develop under Unix and use
cross-platform tools so that I don't have to touch Windows very much.
This way, my customers have a choice, but a lot of them are still
going to choose Gatesware and I need to provide that.
(My own take is that the vast majority of PC users really don't
care what operating system they can run, as long as they can go to the
store, buy a piece of software and just have it work. People who care
about OSs have mostly already switched to something else. But that's
beside the point.)
What you missed is that PMK is aimed to POSIX systems.
The bit I saw was that it was supposed to be a
replacement for GNU autoconf. Autoconf is designed to automate away
the differences between platforms and if PMK is restricted to POSIX,
that makes it insufficiently flexible for my purposes.
(Autoconf is designed to work on non-POSIX systems. That's
why the shell code is so hacky--it's got to work around every Unix's
own shell wierdness.)
If someday someone has interests to make a PMK port for windows then
he just have to contact me or another member of the team. We'll be
happy to help him using the common base for a specific port (and also
to include him in the team of course).
Ah. Well, I seem to have misunderstood the FAQ item then. I read
it as meaning that you would never support Cygwin (or Windows, by
extension) because of the '.EXE' thing. It might be worth clarifying
your stance on that.
In any case, you've written a program designed to automatically
take care of all of the quirky differences between platforms, then
refused to support one of the more common platforms because it's got
all of these quirky differences. Do you see why I'm not all that
enthusiastic about it?
Oh,BTW i have no problem to boycott the "most popular" game console
OS. Yes i meant windows:)
You are, of course, entitled to do this--it's your project after
all. But it's sort of like wolves boycotting sheep. Microsoft
benefits from lock-in. The easier it is to port applications to (and
from) Windows, the easier it will be for your average person to
migrate away from Windows.
I took a quick look at pmk a while back. I got as far as this FAQ entry:
7. Why not supporting cygwin?
Because cygwin is not handling executable files as it should. It is absurd to have to take care about a trailing'.exe' under a Unix-like environment.
Absurd it may be, but Windows is the most popular platform out there and refusing to support it because it's too icky is just plain dumb. They've refused to make pmk useful enough to actually be valuable to me, so I haven't bothered using it for anything.
...but there's nothing unlawful about telling an employee to train his replacement.
It is illegal to fire someone in a nasty or humiliating way and it was recently ruled that forcing the employees to train their (foreign outsourced) replacements counted as such.
And no, I don't have a citation handy. I learned this by talking to my cousin the labour lawyer. (What? Hearsay? On Slashdot? Never!)
The Canadian federal government has virtually no authority to regulate employment relationships outside a few industries
One thing that hasn't been mentioned is Canadian labour laws. In Canada, they are:
Reasonably pro-worker. I'd rank them as very roughly in the same league as those of the most liberal US states (but IANAL). For example, it's illegal for a company to make employees train their Indian replacements before they are laid off. Really.
Federal laws. That is, they are consistant nation-wide. (This is the case with pretty much all laws more serious than traffic and littering).
There's a lot more legal recourse here, so when the companies screw over their employees, they at least have to use lube.
I hear a lot of talk about binary compatibility with Windows, but not so much about source-code-level compatibility. What sort of efforts, if any, are being made toward letting people trivially recompile existing Windows programs to run natively under Linux/X? Have any commercial software vendors considered taking this approach?
If linux were as pervasive as windows, it would have spyware on
it too
That's a common argument (also used for viruses) but I don't think
it's correct. There are several things about Linux that makes it more
secure:
Windows has a culture of running everything as a privileged user
(or has no concept of non-privileged users at all), so a downloaded
program usually has the run of the system. Linux (and other Unixes),
on the other hand, are designed around the assumption that some of the
users will be hostile k1dd13z. For spyware to work under Linux, it'll
need to be deliberately installed by root.
Windows installers (e.g. Install Shield) tend to be in the
package itself, while Linux package installers are part of the core OS
(e.g. rpm). That means that under Linux, you can always uninstall and
always check for files not in the package database when you're looking
for tricklers.
Linux is extremely diverse. Each distribution will do a lot of
things differently and it'd be a real nightmare to write spyware
that's compatitible with all of them. Not impossible, granted,
especially if one vendor gets a majority of the market share, but
still.
Internet Explorer and Outlook Express both have some pretty
serious security problems. I'm not just talking about bugs,
here--there's a concious decision to prefer usability over security.
OE is so helpful and friendly that it'll automatically run
executable attachments and IE routinely links to downloaded DLLs
(i.e. ActiveX components). And almost every Windows user in the world
routinely uses these programs. Meanwhile, the Unix community figured
out that automatically running untrusted code is a bad thing some
twenty years ago.
Speaking of IE and OE, those are pretty much the standard
web browser and mailer under Windows. Linux has no such thing and
Linux spyware will need to be compatible with a whole lot of different
programs to hit any kind of market segment.
Through COM, IE is scriptable. Some Linux web browsers have
similar interfaces, but not all and those that do don't do it the same
way. So making popups appear when you browse the web is going to be a
lot harder if not impossible.
Then, there's the whole open-source/closed-source security
debate, which has already been hashed-over to death here.
So there are some fundamental things that would make Linux spyware
difficult. Whether it's difficult enough that to make spyware not
worth the bother is another question.
I realize you're being deliberately obtuse here, but on the off chance that you're making a legitimate, honest comment, let me clarify:
My point is that engineers become good by tinkering with stuff. Anti-circumvention laws make tinkering illegal. No tinkering leads to to poor engineers (and programmers and scientists) which leads to lack of innovation which leads to general poverty.
We're seeing how, in the third world, widespread education is drasticly reducing poverty, right? Well, tinkering with stuff is self-directed education of the sort we North-Americans desperately need and making it illegal in a country where innovation is the only remaining industry is just plain stupid.
Maybe, if he's really lucky, Mr. Valenti will live long enough to see the beginnings of what he's done.
Okay, can somebody put this in politer, more persuasive language...?
"Those thousand engineers will have to invent the things American businesses sell so that they can pay the salaries of those twenty-four million movie-buying Americans."
There. Short and.siggable.
The thing to remember about these sorts of people is that it's all about the money. They don't care about your hardware hacking projects and freedom is one of those abstract things, but say that this will make them poor and they'll take notice.
Changing the license afterwards [...] it is like shutting the gate after the horse has bolted.
Not true. The CC license gives you extra rights. It doesn't take them away. Before Klowner released them under the CC license, the only permission he gave was to download the images for personal use and he only did that implicitly by uploading them to a wallpaper website.
Linwhatever never had the right or permission to use those images in their Flash demo.
Assuming a sufficiently Unixy system (where Windows or OS/2 with
their respective open-source POSIX-ish layers count), I usually go
with, in no particular order:
Emacs or (preferably) XEmacs built to use the system GUI.
bash/zsh/tcsh or whatever Unix-like shell I can get so long as it
has good filename completion and command history.
Some terminal emulator. I usually default to rxvt but I'm not
too picky as long as it can show more than 50 lines.
A collection of Unix command-line tools. GNU coreutils are my
favourite but I'll take any sufficiently non-sucky toolkit.
Perl. I absolutely need this.
A decent web browser, usually Opera or Mozilla.
mutt
vim (preferred) or nvi, because classic vi just sucks.
GNU make, because so many things depend on it.
Some decent command-line-drive C compiler/linker/debugger,
ideally gcc if only because I know it well.
This is all kind of moot on major Linux distros (which are what I
mostly use) since you get everything you could ever possibly
need with those and I just install it all instead of wasting time
picking the packages I want.
Under the SysV Unix systems I've used, the core utilities are
usually good enough for my tastes as is the C compiler (although you
often have to buy it separately). Getting a decent web browser has
been tricky so I make do with lynx or an old version of Netscape,
depending. Perl is mostly standard these days.
Under Windows, I don't bother with firewalls or antivirus
software. I just use an external router to block all ports, then
make sure to never, ever use IE or Outlook Express. This has worked
for me so far, although I don't use Windows very much and so it could
just be the law of averages in my favour so far.
When I type the "}" character. Ah, but that's exactly as many keystrokes as I need to type to end a Python block, so I see your point. Of course, I could configure XEmacs to insert a closing bracket on its own line whenever I type "{", at which point you'd bring up that I'd still have to move the cursor past the closing brace. To that, I'd argue that sure, that's true but curser movement is easier.
I know for a fact that Notepad is Python-friendly.
Hi Paul.
It's quite likely that I heard it wrong, or my co-worker heard it wrong or that this is a problem with some ancient, moldy version of Notepad that got fixed last century, so I bow to your expertise. Still, I think my point is valid. Lots of tools don't respect whitespace, and that's a serious problem if Python code gets run through one of them.
Slashdot Mirror
False. Selective beeding and natural selection both involve the addition (through "natural" radiation, "natural" chemical mutagens, and "natural" retroviruses) of genes that weren't there before.
Okay, granted. Various natural things do cause mutation and cross-species gene travel and yes, selective breeding (both natural and 'man-made) do bring those to dominance, but that's still different from genetic engineering.
Natural processes are random, which means that most natural mutations either immediately kill the recipient or cause it to be less successful, therefore removing themselves from the gene pool. The chances of a mutation staying in the gene pool are pretty low. This means that the rate at which we get new species is slow, to the point where you almost never see it happen.
In contrast, engineered species are already immediately viable and, because they're useful to people, will stay in the ecosystem for some time. We know the ecosystem can handle normal evolution reasonably well but we have no idea what this sort of rapid change will do.
I'm not opposed to genetic engineering, BTW. It's just that what the big corps are doing right now strikes me as the biological equivalent of a programmer slapping some code together, testing it a couple of times to make sure it doesn't crash and then installing it on the fly-by-wire system of every airliner in the world.
What is the problem with "genetic engineering"? We've been doing it for ages with breeding, as has "nature."
What we traditionally call "genetic engineering" is different from breeding or natural selection because it adds genes that weren't there before while breeding just juggles them about. And the problem with it is that we don't yet understand this sort of DNA manipulation or its consequences well enough to know what will happen when we dump it into the ecosystem. And yet we--or at least Monsanto's customers--are.
I don't agree with the thinking behind a lot of the anti-GM groups but I think that, for the moment anyway, I agree with their goals.
For Example; if you're running XFree86, find the file(s) "Xaccess" and change the "#*" and "#* CHOOSER BROADCAST" to "!*". This will reject any requests for a logon window (which is maybe where you get the assumption that the login service is exploitable via the network).
I don't remember how to do it anymore, but I used to have that port closed as well. It seems that X will happily use Unix-domain sockets (i.e. tied to the filesystem and therefore not networked). This means that you can run a Linux workstation with no ports open.
This is all a moot point to me these days since I use a router. However, in my recent dabblings with Fedora, I noticed that it now blocks all but a few ports with iptables and provides a handy clickable interface to select which services you want to offer. I think that qualifies and pretty close to the ideal, although I don't know for sure what's turned on by default, not having done the actual install.
I know I'm feeding the Troll[...]
The trollish "mistake" here is failing to distinguish background processes ("daemons") with network-accessible services. Most of the essential Linux services don't touch the networking system at all.
Two things:
Alrighty, then.
This is profoundly stupid because, ta dum, there's no market for it, and no prospect of a market for it.
Yup.
See, this thing is designed to solve the producer's problem rather than the consumer's. The problem, in this case, is that the movie companies aren't making enough money off of rentals. Movie studios get a royalty for each DVD sold, so if you buy a DVD and then rent it out a bunch of times, they get a cut of your initial purchase price but you get all of the rental fees.
This is, in part, why DVDs are so cheap to buy--they're trying to compete with the rental market. Every time you buy a movie instead of renting it, Hollywood gets the royalty instead of the video rental place.
This is just more of the same. If you buy a self-destructing DVD, the effect is the same as a video rental for you (in theory, anyway) but it goes through the same channels as sale DVDs and so Hollywood gets a cut of it.
Will it work? It hasn't so far and my guess is that they won't. From what I've seen so far, it looks to me like they can't make them cheap enough to compete with the video rental places. There seems to be a whole lot of wishful thinking going on here. Still, with that kind of money hanging in front of them, it's very easy to see how the can forget the basic capitalist principal of selling stuff people want to buy.
BTW, the last producer-driven product I can think of was the Cue::Cat. Remember what a well-thought-out success that one was?
When I do Windows development, I do the actual development under something Unixish and port the result to Windows, typically with the help of a cross-platform GUI toolkit.
My reasons for not developing under Windows are:
As a user, I'd probably use Windows a little--to play some games and run the occasional interesting app--if only it weren't so freaking expensive. I've seen computers for sale that cost less than just the standalone license for the version of Windows they have pre-installed.
If I could get a (legal) copy of XP for sixty bucks, I probably would. But I can't, so I'll just have to keep my money.
As it happens, there is another POSIX-ish kernel that was written by a student in about a year. That's the Thix operating system.
(I played with it once and it wasn't very impressive, but from my casual examination, it seemed at least as advanced as Linux 0.01.)
What I want to know is where the encryption actually happens. I have a sneaking suspicion that it's all done on the PC side with the included software. Can anyone confirm or deny this?
Has anyone thought the only way to combat this maybe to have the FSF start patenting things?
What the FSF (or some similar organization) should do is start a defensive patent pool. (A patent pool is a collection of patents that may be licensed as a single unit, often held by different entities.) The rules would be:
Such a scheme would benefit FOSS developers, small ISVs and any company that uses software patents only defensively. The bigger the pool gets, the more economic sense it makes for a company to join as the potential revenues of their patent portfolios get dwarfed by the money they could save by not having to license pool patents.
The only people it doesn't help against are the true leeches, those folks that obtain patents solely to extort money from actual R&D firms. They don't need to license patents because they don't have an actual product. Of course, they also don't contribute to the arts and it's not inconceivable that the laws may be changed at some point to exclude their business models.
After all, the real makers usually have a lot more money.
The author is probably right about Microsoft hating the web, and he might even be right in his assertion that Longhorn is their attempt to replace it with their own thing, but he's wrong in assuming they even have a chance.
There are two reasons.
Firstly, the web is about small voices. It's not a medium for selling stuff or issuing press releases (although some people have made money doing that), it's about ordinary people saying stuff.
Remember how the web used to be, before VCs with their carpet bags full of money turned great swaths of it into a cheap version of UHF TV? Doesn't the thought of all the weasels switching to MS-Internet and going away bring a smile to your face?
Alas, it will not be, for the second reason the Longhorn Strategy will fail. Because breaking web compatibility means turning away customers and that's just not good for businesses.
Notice that all the commercial websites still around will work, at least mostly, on all sorts of browsers? Coincidence? I think not! Amazon tests their sites using Netscape 1.x! (Or they used to for a long time anyway--I don't know what their baseline is now.) That way, they know that their site will work on practically every browser out there, right out of the box.
Of course, some of the bigger e-business folks may start supporting Longhorn, but they'll stay compatible with the established standards because they don't want to lose their customers.
At this point, everyone has W3C-compliant (more or less) browsers and servers. They can all talk to each other. As soon as someone switches, they can't talk to the rest anymore and their setup becomes useless. This is why, for example, nobody has been able to replace SMTP, despite the whole spam problem.
I predict that we'll remain stuck with HTML, CSS and HTTP for a long time. The MS extensions will be a kewl technological blip that nobody will use but, if it's good, may well be lamented by future web developers as something that could have been.
Yay, a flamewar! I'll join!
I'm not usually very good at flamewars, so just pretend I wrote a lot of incoherent abuse here.
Asserting that developers are dumb because they do not support a system that was designed to be incompatible is, I would say, misguided.
If you go back and read my post, you will see that I'm referring to the behaviour as dumb, not the people. That's a big distinction. These folks have written a working non-trivial software package and that requires some smarts. I'm talking about one particular decision of theirs.
But anyway, let me spell out my reasoning:
I mean, not supporting Windows is all well and good (and the sort of thing I do on occasion) but when your stated goal is to make software more compatible across platforms, you can't do that without making yourself a liar.
I could understand it if they'd said, "we're looking for someone to do a Cygwin port because we can't be bothered." But what they said was, "Cygwin is broken and we're not going to work around the problem because they should fix it." This for a tool whose very purpose is to work around those sorts of problems.
(Note: see my followup to Damien one thread over. I may have partially misunderstood their position on this, in which case I could be wrong in my claims of dumb behaviour. But this is how I see things and my conclusions are derived from that.)
And by the way, I challenge your statement that Windows is the most popular platform. It may be the most used platform on desktops, but it's not like every user willingly chose to use it.
Whether or not people like it is irrelevant to my argument. Windows is the operating system of most of the desktop computers in the world. If you want to write a program and have it work on the biggest number of computers possible, you have to make sure it works under Windows. As a developer, the best I can do is develop under Unix and use cross-platform tools so that I don't have to touch Windows very much. This way, my customers have a choice, but a lot of them are still going to choose Gatesware and I need to provide that.
(My own take is that the vast majority of PC users really don't care what operating system they can run, as long as they can go to the store, buy a piece of software and just have it work. People who care about OSs have mostly already switched to something else. But that's beside the point.)
What you missed is that PMK is aimed to POSIX systems.
The bit I saw was that it was supposed to be a replacement for GNU autoconf. Autoconf is designed to automate away the differences between platforms and if PMK is restricted to POSIX, that makes it insufficiently flexible for my purposes.
(Autoconf is designed to work on non-POSIX systems. That's why the shell code is so hacky--it's got to work around every Unix's own shell wierdness.)
If someday someone has interests to make a PMK port for windows then he just have to contact me or another member of the team. We'll be happy to help him using the common base for a specific port (and also to include him in the team of course).
Ah. Well, I seem to have misunderstood the FAQ item then. I read it as meaning that you would never support Cygwin (or Windows, by extension) because of the '.EXE' thing. It might be worth clarifying your stance on that.
In any case, you've written a program designed to automatically take care of all of the quirky differences between platforms, then refused to support one of the more common platforms because it's got all of these quirky differences. Do you see why I'm not all that enthusiastic about it?
Oh,BTW i have no problem to boycott the "most popular" game console OS. Yes i meant windows :)
You are, of course, entitled to do this--it's your project after all. But it's sort of like wolves boycotting sheep. Microsoft benefits from lock-in. The easier it is to port applications to (and from) Windows, the easier it will be for your average person to migrate away from Windows.
I took a quick look at pmk a while back. I got as far as this FAQ entry:
7. Why not supporting cygwin?
Because cygwin is not handling executable files as it should. It is absurd to have to take care about a trailing'.exe' under a Unix-like environment.
Absurd it may be, but Windows is the most popular platform out there and refusing to support it because it's too icky is just plain dumb. They've refused to make pmk useful enough to actually be valuable to me, so I haven't bothered using it for anything.
It is illegal to fire someone in a nasty or humiliating way and it was recently ruled that forcing the employees to train their (foreign outsourced) replacements counted as such.
And no, I don't have a citation handy. I learned this by talking to my cousin the labour lawyer. (What? Hearsay? On Slashdot? Never!)
The Canadian federal government has virtually no authority to regulate employment relationships outside a few industries
Ahem. Cough cough .
One thing that hasn't been mentioned is Canadian labour laws. In Canada, they are:
There's a lot more legal recourse here, so when the companies screw over their employees, they at least have to use lube.
I hear a lot of talk about binary compatibility with Windows, but not so much about source-code-level compatibility. What sort of efforts, if any, are being made toward letting people trivially recompile existing Windows programs to run natively under Linux/X? Have any commercial software vendors considered taking this approach?
If linux were as pervasive as windows, it would have spyware on it too
That's a common argument (also used for viruses) but I don't think it's correct. There are several things about Linux that makes it more secure:
So there are some fundamental things that would make Linux spyware difficult. Whether it's difficult enough that to make spyware not worth the bother is another question.
And so, laughing maniacally, the music industry snatches the gun from Apple and begins frantically shooting the stumps at the ends of its legs.
Shit, a lot of inventors don't even watch TV.
I realize you're being deliberately obtuse here, but on the off chance that you're making a legitimate, honest comment, let me clarify:
My point is that engineers become good by tinkering with stuff. Anti-circumvention laws make tinkering illegal. No tinkering leads to to poor engineers (and programmers and scientists) which leads to lack of innovation which leads to general poverty.
We're seeing how, in the third world, widespread education is drasticly reducing poverty, right? Well, tinkering with stuff is self-directed education of the sort we North-Americans desperately need and making it illegal in a country where innovation is the only remaining industry is just plain stupid.
Maybe, if he's really lucky, Mr. Valenti will live long enough to see the beginnings of what he's done.
At least I can still get the plugin code through a file sharing network.
Okay, can somebody put this in politer, more persuasive language...?
"Those thousand engineers will have to invent the things American businesses sell so that they can pay the salaries of those twenty-four million movie-buying Americans."
There. Short and .siggable.
The thing to remember about these sorts of people is that it's all about the money. They don't care about your hardware hacking projects and freedom is one of those abstract things, but say that this will make them poor and they'll take notice.
Changing the license afterwards [...] it is like shutting the gate after the horse has bolted.
Not true. The CC license gives you extra rights. It doesn't take them away. Before Klowner released them under the CC license, the only permission he gave was to download the images for personal use and he only did that implicitly by uploading them to a wallpaper website.
Linwhatever never had the right or permission to use those images in their Flash demo.
Period.
Assuming a sufficiently Unixy system (where Windows or OS/2 with their respective open-source POSIX-ish layers count), I usually go with, in no particular order:
This is all kind of moot on major Linux distros (which are what I mostly use) since you get everything you could ever possibly need with those and I just install it all instead of wasting time picking the packages I want.
Under the SysV Unix systems I've used, the core utilities are usually good enough for my tastes as is the C compiler (although you often have to buy it separately). Getting a decent web browser has been tricky so I make do with lynx or an old version of Netscape, depending. Perl is mostly standard these days.
Under Windows, I don't bother with firewalls or antivirus software. I just use an external router to block all ports, then make sure to never, ever use IE or Outlook Express. This has worked for me so far, although I don't use Windows very much and so it could just be the law of averages in my favour so far.
How does XEmacs know when the block is done?
When I type the "}" character. Ah, but that's exactly as many keystrokes as I need to type to end a Python block, so I see your point. Of course, I could configure XEmacs to insert a closing bracket on its own line whenever I type "{", at which point you'd bring up that I'd still have to move the cursor past the closing brace. To that, I'd argue that sure, that's true but curser movement is easier.
But then, things would start to get silly.
I know for a fact that Notepad is Python-friendly.
Hi Paul.
It's quite likely that I heard it wrong, or my co-worker heard it wrong or that this is a problem with some ancient, moldy version of Notepad that got fixed last century, so I bow to your expertise. Still, I think my point is valid. Lots of tools don't respect whitespace, and that's a serious problem if Python code gets run through one of them.