I used to have a TV and its vertical yoke died one day. When messing with
the potentiometers in the back to try to adjust the picture back to a
working state, I quickly discovered that the electron beam that scans the
inside of the picture tube is extremely strong and produces a very
bright spot on the screen.
When you think about it, though, the phenomenon makes a lot of sense. The
beam is as bright as (average pixel brightness) * (total pixels on the
screen). If you concentrate the brightness of the entire screen on
one point, that point is going to be very bright and may well be
damaged.
And that brings us to the problem here. If you burn the phosper off a
little dot on your TV's picture tube, it's not the end of the world - you
can just buy a new TV. But if you burn a spot in your retina, it's
there forever unless you can get an eye transplant. If you used such a
low-power laser or electron beam that this wouldn't happen, your picture
would be too dim to see.
I have been a software developer for the past 17 years. I have worked with
DOS, Windows, UNIX, VMS, OS/390, and many other platforms. And I have to
wonder whether you're really looking for a drop-in replacement for Visual
Studio, or if you're looking to maximize developer and end-user
productivity. And if the latter is the case, I have some recommendations
for you.
I am aware that commercial IDE environments for MS-Win32
development look nice and have many pleasing buttons, but where
is the _real_ functionality?
I have seen _nice_ development front-end tools.
I submit that you have not seen the range of tools available,
and that your area of development has not required the real,
heavy-duty tools which UNIX offers. Or, I should say, you have
not _percieved_ this requirement, and the benefit which
such tools would offer you in your development arena.
What you speak of (commercial Win32 IDE environments) offer:
IDE with color syntax highlighting
Online manuals for function calls and syntax elements
at a button-press
Ability to arrange a GUI framework, and generate code for same,
by dragging some things about in a GUI fashion
Compile and link projects with a button press
Run and inspect (or interpret and inspect) programs with
a button press
Development environments in the UNIX world offer _always_:
Pipeline-capable tools
A real scripting environment to put them together
in powerful ways
Said tools, used together as above, include:
automate project regeneration, recompilation
of course of arbitrary nature (make, GNU Make)
automate project compilation/installation
cross-platform, cross-OS (Imake, GNU autoconf)
programatically generate parsers and lexers
(lex/flex, yacc/bison)
Check syntax/portability semantics (lint),
Pretty-print source code in various languages,
Find and print patterns (grep),
Extract strings from binaries (strings),
Index symbols in source code(ctags/etags),
Perform powerful macro expansions (preprocessing)
of arbitrary nature (m4, notably),
(and remember where you got the _C_ preprocessor from)
Create function libraries (of static/dynamically
loaded nature, as supported by host OS) (ar, etc)
Generate documentation in (plaintext, HTML, PostScript,
{La}TeX, others) programatically from source code (many free
and commercial, 3rd party tools, portable to any UNIX),
High quality online documentation in the form
of manpages, GNU texinfo/info documents,
as well as any vendor-specific documentation
in various formats.
...and others I or any other person familiar with the Unix
environment could list
Those were the basics, and available for _every_ UNIX.
Notable higher-level environments worth noting include:
Emacs: at a _minimum_, Emacs can be considered to be
an IDE of a very superior nature, with elisp
programming primitives for editor macros
of arbitrary complexity/sophistication/power.
Emacss' ability to create and use "major modes"
for editing of arbitrarily many different
languages in a language-specific, nice way,
with color syntax highlighting, etc, are
not matched by any PC-based IDE I have ever seen,
nor expect to.
GDB: a debugger of certainly adequate power, able
to take advantage of UNIX environment concepts
such as core files, as well as debugging of
actively running programs (and work-in-progress
for debugging running _kernals_, both locally
and remotely).
Correct me if I am wrong as to state-of-the-
debugging-art outside of the UNIX world, but
I don't recall any mature tools for debugging
MS-Win32 (or Win16) device drivers, which are
analogous in difficulty and usefullness to
debug, and _very_nasty_ to get wrong...
GCC: an eminently capable compiler, capable of
(K&R, ANSI) C, C++, and Objective C
(plus the languages using C as backend,
such as some Pascal compilers, etc)
Granted, this compiler has significant faults,
so do all MS-environment compilers I have heard of.
The big advantage though, is the cross-OS,
cross-platform compilation.
Emacs + GDB + GCC + other tools integrated:
The GNU development environment is _very_
powerful, as an integrated system.
NEXTSTEP/OpenStep: Interface Builder/Project Builder
a very powerful framework. Useful analogies
can be made to DELPHI, which you may be familiar with,
and which is based on Object Pascal rather than
Objective C.
I submit that, contrary to your assumption of
MS-environment tool superiority, you are tool-starved
outside the UNIX world, and many of your best tools
(which are buried inside your comfy IDEs) are
derived from UNIX tools.
You do not have enough tools.
They are not available to use separately, low-level.
You have no way to combine small, single-purpose,
low-level tools into larger useful units.
Your tools are not mature by comparison
(read: buggy, unpredictable, undocumented, proprietary)
Your higher-level tools are not built on a firm
basis (excellent low-level tools),
and if something breaks, it's REALLY REALLY BROKEN,
and you are mostly screwed unless you are intimate
with the vendor of the tool
Linux is the most developer friendly environment I have ever used, and I
can't see why any serious software engineers would even consider Windows a
viable alternative at all. It may take a bit of pursuading on your part,
but the reduced cost and ease of coding for Linux make the decision a
no-brainer.
As Tom Pabst, a speed addict himself, was quoted as saying, anything above
1Ghz is nothing but overkill for most users.
The vast majority of systems that are being sold today are somewhere around
the 1Ghz mark. They represent the "sweet spot" on the price/performance
curve, and quite frankly, users just don't need anything better.
Open source OS users, such as most of us here, don't need to ratchet up the
speed to 1.5Ghz unless they're running a bleeding edge release of the
bloated KDE 2. Windows XP runs just great (well, as well as Windows XP
can run, anyway;) on my Duron 900.
Desktop users don't need anything faster than 1Ghz. So what's Intel's
brilliant strategy? Why, they're going to develop chips that are even
faster than the overpriced 2Ghz P4s they're having difficulties
unloading right now.
And that, my friends, is why AMD is well on its way to winning the war.
Intel is putting a product on the market without bothering to notice that
nobody needs anything faster. They will lose a lot of money doing this (a
friend at Intel pegged the development costs for this chip at $3.7
billion). AMD is sitting tight and refining their core business: solid,
stable, speedy, and inexpensive chips that consumers can afford and that
consumers actually want to buy.
If I were a stock broker, I would be telling all of my clients to short
Intel and go long on AMD right about now. The revolution is underway and
the underdog is winning.
There is much confusion in the Linux community over the fact that the Linux
architecture is well-suited to run on older hardware. Many (such as the
submitter) seem to think it is a design decision that is fundamental to the
very concept of Linux. However, as Linus and other have stated many times
in the past, good performance on older machines is only a side effect of
the Linux community having developed a modular, streamlined system based on
the proven UNIX paradigm. It is purely incidental that Linux
performs well regardless of the hardware it is run on.
And that brings us to my point: making software compatible with older
hardware shouldn't be a goal in and of itself. Why? One need only
to venture over to Pricewatch to see that an AMD 1800+ mobo/CPU combo sells
for under $300. Systems faster than what anyone could ever need are
commodities now. The only people who need Linux to run on old hardware are
the Luddites who refuse to part with their old equipment, and they are
nothing but an albatross around the neck of the Linux community. Let's
face it - we all need to grow up, evolve, and keep up with new
developments. We can't let our programming skills atrophy for 2-3 years
and expect to pick up where we left off, so why should we all be bending
over backwards to support machines that were made in 1996? The industry
changes and it's time for us all to realize that our skills, our paradigms
and mindsets, and yes, our hardware too must change.
My mistake, I didn't mean to write "can't legally be sold at a profit."
I did mean to convey that there's nothing Sony can do to force people to pay for the software.
But they're still being greedy. They're slapping a $199 price tag on some cheap commodity hardware and some Free software. Consumers would be a lot happier if they just shipped the PS2 with Linux off the bat instead of trying to gouge us.
Although the price tag may sound steep, especially if you're like me and
have most of the parts (hard drive, USB keyboard, etc.) left over from your
former dot-com job, third-party vendors are hard at work to make your PS2
Linux experience more pleasurable and cost-effective. Some of the PS2
hardware that I've seen on sale at eBay and on Usenet are:
VGA monitor adaptor: $7. There's no logic in the thing; it's
just a cable with two connectors.
USB keyboard and mouse kit: $15. It's no "Microsoft Natural"
keyboard but a cheap Taiwanese knockoff will do the job just fine.
Linux CD-ROMs: $2 - $23. One was a prerelease of the Sony
distribution, and one was a hacked up version of Debian, complete with a
Playstation apt source preinstalled.
Network adaptor: $22. It uses the Xircom adaptor, IIRC.
Used 20GB hard drive: $47. It's even a 7200rpm ATA-66 dealie.
The point being, of course, that Sony is being very opportunistic with its
Linux release. All of the hardware can be had for well under $100, and the
software is Free as in GPL and can't legally be sold at a profit.
But what else did you expect from a member of the RIAA cartel?
IANAL, but my experience as a software developer has made me very
suspicious of Draeker's quote:
...after we bring our operations to a halt in an orderly fashion,
we will make the source code to all of our products publicly available
under the GPL.
Since Loki only worked on ports of existing games and didn't (as far
as I have heard) purchase full rights to the existing games' source code,
what gives them the legal right to release the original authors' code into
the public domain? Are they just doing it because there's nobody left to
sue?
Any way you look at it, though, it will definitely be a victory to open
source to have such a substantial amount of game source code out there
now.
Having worked with Darren Reed a few years ago on another project, I am not
surprised at his latest maneuver. In fact I would argue that his original
intention in bringing the ipf license issues to light was to wrench control
of OpenBSD from Theo de Raat. Theo and Darren are both very abrasive
people who have a tendency to become control freaks when they're dealing
with something they care a lot about.
It is ironic, yet just desserts, that Theo is now losing control of the
OpenBSD project, to a man with whom he has had many personal spats in the
past. Those of you who don't remember the history of the OpenBSD project
will note that Theo did the exact same thing to put NetBSD out of business
in the mid-90s. Although Darren has some big shoes to fill with regard to
OpenBSD's rigorous auditing and feature assimilation, he has shown himself
to be an excellent coder and project manager in the ipf project and in
other open source efforts, so I have few doubts about his ability to pull
it off. The whole thing kind of reminds me of the Homer/Grimes rivalry on
that one Simpsons episode - one of the guys always loses in a big way, and
in this case it was Theo.
As the final project for my Engineering Law class last semester, we studied
this issue at length and even read the documents the PTO released under
FOIA justifying their acceptance of the Kamen patent. Some of the major
points we found were:
Kamen has been working on the Segway for a lot longer than 15
years. Most people don't realize how old Dean Kamen is; Yamafuji probably
was just a young tot when Kamen introduced his "cripple cart."
The Segway employs a sophisticated transmission system that adjusts
gear ratios depending on how difficult the terrain is (uphill, flat, or
downhill) and the desired speed. This improves battery life and
performance. Kazou's project had no such feature.
As was clearly stated in the patent, Kamen used a gyroscope while
Yamafiji used a clumsy set of concentric rings and Hall effect sensors.
It's like the difference between using GNOME 1.0 and KDE 2.0 - there's just
no comparison.
Kamen's software was considerably more streamlined because it was
written as a true embedded system, in pure ASM. Yamafiji's model used C++
because, well, it was just a model and it would have been useless if it
were not hooked up to the portable computer he used to build it.
Kamen deserves every penny he can make frmo Segway, both here and in Japan.
For once, the USPTO did the right thing - and the media owes it to DK to
stop complaining.
Slashdot Mirror
When you think about it, though, the phenomenon makes a lot of sense. The beam is as bright as (average pixel brightness) * (total pixels on the screen). If you concentrate the brightness of the entire screen on one point, that point is going to be very bright and may well be damaged.
And that brings us to the problem here. If you burn the phosper off a little dot on your TV's picture tube, it's not the end of the world - you can just buy a new TV. But if you burn a spot in your retina, it's there forever unless you can get an eye transplant. If you used such a low-power laser or electron beam that this wouldn't happen, your picture would be too dim to see.
Mr. Uptime
I am aware that commercial IDE environments for MS-Win32 development look nice and have many pleasing buttons, but where is the _real_ functionality?
I have seen _nice_ development front-end tools. I submit that you have not seen the range of tools available, and that your area of development has not required the real, heavy-duty tools which UNIX offers. Or, I should say, you have not _percieved_ this requirement, and the benefit which such tools would offer you in your development arena.
What you speak of (commercial Win32 IDE environments) offer:
- IDE with color syntax highlighting
- Online manuals for function calls and syntax elements
at a button-press
- Ability to arrange a GUI framework, and generate code for same,
by dragging some things about in a GUI fashion
- Compile and link projects with a button press
- Run and inspect (or interpret and inspect) programs with
a button press
Development environments in the UNIX world offer _always_:Pipeline-capable tools
A real scripting environment to put them together in powerful ways Said tools, used together as above, include:
automate project regeneration, recompilation of course of arbitrary nature (make, GNU Make)
automate project compilation/installation cross-platform, cross-OS (Imake, GNU autoconf)
programatically generate parsers and lexers (lex/flex, yacc/bison)
Check syntax/portability semantics (lint),
Pretty-print source code in various languages,
Find and print patterns (grep),
Extract strings from binaries (strings),
Index symbols in source code(ctags/etags),
Perform powerful macro expansions (preprocessing) of arbitrary nature (m4, notably), (and remember where you got the _C_ preprocessor from)
Create function libraries (of static/dynamically loaded nature, as supported by host OS) (ar, etc)
Generate documentation in (plaintext, HTML, PostScript, {La}TeX, others) programatically from source code (many free and commercial, 3rd party tools, portable to any UNIX),
High quality online documentation in the form of manpages, GNU texinfo/info documents, as well as any vendor-specific documentation in various formats.
...and others I or any other person familiar with the Unix environment could list Those were the basics, and available for _every_ UNIX. Notable higher-level environments worth noting include:
- Emacs: at a _minimum_, Emacs can be considered to be
an IDE of a very superior nature, with elisp
programming primitives for editor macros
of arbitrary complexity/sophistication/power.
Emacss' ability to create and use "major modes"
for editing of arbitrarily many different
languages in a language-specific, nice way,
with color syntax highlighting, etc, are
not matched by any PC-based IDE I have ever seen,
nor expect to.
- GDB: a debugger of certainly adequate power, able
to take advantage of UNIX environment concepts
such as core files, as well as debugging of
actively running programs (and work-in-progress
for debugging running _kernals_, both locally
and remotely).
Correct me if I am wrong as to state-of-the-
debugging-art outside of the UNIX world, but
I don't recall any mature tools for debugging
MS-Win32 (or Win16) device drivers, which are
analogous in difficulty and usefullness to
debug, and _very_nasty_ to get wrong...
- GCC: an eminently capable compiler, capable of
(K&R, ANSI) C, C++, and Objective C
(plus the languages using C as backend,
such as some Pascal compilers, etc)
Granted, this compiler has significant faults,
so do all MS-environment compilers I have heard of.
The big advantage though, is the cross-OS,
cross-platform compilation.
- Emacs + GDB + GCC + other tools integrated:
The GNU development environment is _very_
powerful, as an integrated system.
- NEXTSTEP/OpenStep: Interface Builder/Project Builder
a very powerful framework. Useful analogies
can be made to DELPHI, which you may be familiar with,
and which is based on Object Pascal rather than
Objective C.
I submit that, contrary to your assumption of MS-environment tool superiority, you are tool-starved outside the UNIX world, and many of your best tools (which are buried inside your comfy IDEs) are derived from UNIX tools.- You do not have enough tools.
- They are not available to use separately, low-level.
- You have no way to combine small, single-purpose,
low-level tools into larger useful units.
- Your tools are not mature by comparison
(read: buggy, unpredictable, undocumented, proprietary)
- Your higher-level tools are not built on a firm
basis (excellent low-level tools),
and if something breaks, it's REALLY REALLY BROKEN,
and you are mostly screwed unless you are intimate
with the vendor of the tool
Linux is the most developer friendly environment I have ever used, and I can't see why any serious software engineers would even consider Windows a viable alternative at all. It may take a bit of pursuading on your part, but the reduced cost and ease of coding for Linux make the decision a no-brainer.Mr. Uptime
The vast majority of systems that are being sold today are somewhere around the 1Ghz mark. They represent the "sweet spot" on the price/performance curve, and quite frankly, users just don't need anything better. Open source OS users, such as most of us here, don't need to ratchet up the speed to 1.5Ghz unless they're running a bleeding edge release of the bloated KDE 2. Windows XP runs just great (well, as well as Windows XP can run, anyway ;) on my Duron 900.
Desktop users don't need anything faster than 1Ghz. So what's Intel's brilliant strategy? Why, they're going to develop chips that are even faster than the overpriced 2Ghz P4s they're having difficulties unloading right now.
And that, my friends, is why AMD is well on its way to winning the war. Intel is putting a product on the market without bothering to notice that nobody needs anything faster. They will lose a lot of money doing this (a friend at Intel pegged the development costs for this chip at $3.7 billion). AMD is sitting tight and refining their core business: solid, stable, speedy, and inexpensive chips that consumers can afford and that consumers actually want to buy.
If I were a stock broker, I would be telling all of my clients to short Intel and go long on AMD right about now. The revolution is underway and the underdog is winning.
Mr. Uptime
And that brings us to my point: making software compatible with older hardware shouldn't be a goal in and of itself. Why? One need only to venture over to Pricewatch to see that an AMD 1800+ mobo/CPU combo sells for under $300. Systems faster than what anyone could ever need are commodities now. The only people who need Linux to run on old hardware are the Luddites who refuse to part with their old equipment, and they are nothing but an albatross around the neck of the Linux community. Let's face it - we all need to grow up, evolve, and keep up with new developments. We can't let our programming skills atrophy for 2-3 years and expect to pick up where we left off, so why should we all be bending over backwards to support machines that were made in 1996? The industry changes and it's time for us all to realize that our skills, our paradigms and mindsets, and yes, our hardware too must change.
Mr. Uptime
I did mean to convey that there's nothing Sony can do to force people to pay for the software.
But they're still being greedy. They're slapping a $199 price tag on some cheap commodity hardware and some Free software. Consumers would be a lot happier if they just shipped the PS2 with Linux off the bat instead of trying to gouge us.
Mr. Uptime
- VGA monitor adaptor: $7. There's no logic in the thing; it's
just a cable with two connectors.
- USB keyboard and mouse kit: $15. It's no "Microsoft Natural"
keyboard but a cheap Taiwanese knockoff will do the job just fine.
- Linux CD-ROMs: $2 - $23. One was a prerelease of the Sony
distribution, and one was a hacked up version of Debian, complete with a
Playstation apt source preinstalled.
- Network adaptor: $22. It uses the Xircom adaptor, IIRC.
- Used 20GB hard drive: $47. It's even a 7200rpm ATA-66 dealie.
The point being, of course, that Sony is being very opportunistic with its Linux release. All of the hardware can be had for well under $100, and the software is Free as in GPL and can't legally be sold at a profit.But what else did you expect from a member of the RIAA cartel?
Mr. Uptime
Since Loki only worked on ports of existing games and didn't (as far as I have heard) purchase full rights to the existing games' source code, what gives them the legal right to release the original authors' code into the public domain? Are they just doing it because there's nobody left to sue?
Any way you look at it, though, it will definitely be a victory to open source to have such a substantial amount of game source code out there now.
Mr. Uptime
It is ironic, yet just desserts, that Theo is now losing control of the OpenBSD project, to a man with whom he has had many personal spats in the past. Those of you who don't remember the history of the OpenBSD project will note that Theo did the exact same thing to put NetBSD out of business in the mid-90s. Although Darren has some big shoes to fill with regard to OpenBSD's rigorous auditing and feature assimilation, he has shown himself to be an excellent coder and project manager in the ipf project and in other open source efforts, so I have few doubts about his ability to pull it off. The whole thing kind of reminds me of the Homer/Grimes rivalry on that one Simpsons episode - one of the guys always loses in a big way, and in this case it was Theo.
Mr. Uptime
- Kamen has been working on the Segway for a lot longer than 15
years. Most people don't realize how old Dean Kamen is; Yamafuji probably
was just a young tot when Kamen introduced his "cripple cart."
- The Segway employs a sophisticated transmission system that adjusts
gear ratios depending on how difficult the terrain is (uphill, flat, or
downhill) and the desired speed. This improves battery life and
performance. Kazou's project had no such feature.
- As was clearly stated in the patent, Kamen used a gyroscope while
Yamafiji used a clumsy set of concentric rings and Hall effect sensors.
It's like the difference between using GNOME 1.0 and KDE 2.0 - there's just
no comparison.
- Kamen's software was considerably more streamlined because it was
written as a true embedded system, in pure ASM. Yamafiji's model used C++
because, well, it was just a model and it would have been useless if it
were not hooked up to the portable computer he used to build it.
Kamen deserves every penny he can make frmo Segway, both here and in Japan. For once, the USPTO did the right thing - and the media owes it to DK to stop complaining.Mr. Uptime