I've contracted to IBM in the past, working at a number of their locations. I knew many people before, during, and since that period who were employees or contractors at IBM. I also know several people from some of their manufacturing plants.
Not one of them has ever hinted at a "sweatshop" as you claim, nor have I ever seen any news articles alluding to such activities. Their employees are not only well paid, but have excellant benefits, solid training programs, and far more say in how their job is done than most other places I've worked at.
In addition, IBM's support of the development community with their "Personal Developer Edition" software is far better than any other company I can think of. How many other companies will sell you a multi-thousand dollar package for the cost of media and shipping so you can use it for training? Sure it gets them more trained people in the field who know their products, but that benefit doesn't seem to be enough to convince any of the other companies to provide similar services.
IBM is a big company, and I'm sure they have their flaws, but your comments have no relevance to reality that I am aware of. If I'm incorrect, please post some links to netzine articles discussing their "sweatshops."
As I'd mentioned, the Plus Pack is a limited themer, more a skinner than anything else.
A themer in the sense of Apple's patent has to be able to change the behavior of the widgets. For example, you might switch the activation button for a spin box between MOUSE1 and MOUSE3, or change URL activation between a MOUSE1 single click and a MOUSE1 double click.
In some cases, the themed widgets might only vaguely resemble each other across themes. One theme might use a common drop-down choice box for selections, another might display a panel of radio buttons. Each performs the same function, but the interface behavior changes.
The Plus Pack, on the other hand, only let you do trivial things like use animated cursors and sounds. The underlying behavior of the widgets didn't change.
Some examples of prior art that would negate this patent:
Neuron Data Open Interface (later known as Elements Environment) used hard coded themes to allow the user to dynamically switch between WinXX, Mac, Motif, etc. "themes" way back in 1989-90. The Mac theme was only enabled on Macs for production, but the development version let you use it on other platforms for the first couple years. It doesn't qualify for the data-driven aspects, however.
Win98 Plus Pack supported visual/audio themes, but not widget behavior changes.
Enlightenment supports themes, but I'm not sure when they started the support.
XVT, the major competitor to Neuron Data's products for cross platform-development, not only supported look-and-feel theming in the late 1980's, but encouraged themed widgets that would adjust their behavior according to the platform simulated.
Java JFC is themable to an insane degree, with the core kit designed to allow the user to define just about every aspect of behavior and feedback. As this work started with Netscape, there is a very good chance it predates May 1998.
I'd also have to question whether Copland is truly Apple's sole invention, and how much actually derives from their partnerships with IBM at that time.
It sounds like a rather general description of the fallback code for Java Servlet sessions. If the client browser doesn't support cookies, you encode the session id in the URLs the client sees.
This is an old, old idea that's been used by CGI programmers for a very long time. I'm quite certain there are hundreds, if not thousands, of prior-art examples.
The idea is so basic that it's given a whole 5 minutes in the first couple days of IBM's Websphere Application Server, Advanced Edition courses and associated documentation. It's also discussed in the Sun books on programming JSPs and Servlets.
It was a generalization regarding the fact that the three letter sequence is not a registered trademark -- the logos are. Yes, IBM will pursue anybody trying to knock off their products, usually successfully.
They don't win because of the law, but because nobody is stupid enough to try to pick a fight with a company whose research budget dwarfs most corporate incomes, that has more lawyers on staff than Microsoft, and that has more backing from the community than any other large corporation.
From that perspective, you're right: they have an implicit "trademark" on the letters. But it's because of clout, not because the law would be on their side. (Ignoring the impact big business has on Congress and legal issues due to the number of voters they employ.)
In a very loose sense I'd have to agree with you, and with the various people who have posted in support of Ylonen's right to defend the SSH trademark.
What I'm having a problem with is that SSH is the acronym for a protocol that has been submitted to standards bodies by the holder of the SSH trademark. By definition anything submitted to the public standards bodies becomes part of the public domain.
Aside from the use of the term in the standards documents, there has been no apparent attempt to stop anyone other than the open source development team from using SSH in the name of their "product." As someone else has pointed out in these threads, trademark defense has to be consistent to be valid.
I'm not sure a trademark on the acronym SSH is valid without being more specific about the design of the trademark. Even IBM's trademarks aren't on the three letters IBM, but on specific color combinations and fonts for their famous corporate logo.
Although I generally don't feel Ylonen is acting in good faith in this matter, I'd rather see us switch to a name like OpenSTN, provided that the documentation submitted to the standards bodies are also updated to use a protocol acronym other than SSH. Whatever acronym is used for the standard is the acronym that should be used by Open???.
I don't agree with comments in this thread that the open source project should have a page crediting and linking the commercial provider's site. If anything, they should be referencing the site and documentation from the standards bodies describing the protocol. Once a standard has been submitted to ISO, ANSI, W3C, or any other such body, it is the standard that becomes important for determining interoperability, not the identity of the originator. Any historical credit for the standard should be referenced by the standards documentation, not by the open source implementation.
The 256 kbit MRAM is already already using 16 chips, near as I could tell from the article, so the post about putting 16 of them on a memory stick is incorrect.
However, I don't think one would need to save the entire state of system memory for this to be useful. Aside from embedded systems, consider the possibility of an OS that uses a proper swap system and just makes sure the entire physical memory is written to swap when the system suspends. If the MRAM is sufficient to keep the core kernel state and information about the swap pages, your restart would just need to flag all the physical memory as free pages, with everything currently swapped out. Sure it wouldn't be "instant on", but it would be far closer than I've seen to date.
On the flip side, you could probably do something similar with Linux by putting in a boot patch that checks the swap space for a signature indicating it should reload the memory from the swap space instead of going through a full boot process. You'd still have the usual issues of needing to reset hardware, but it would probably be faster than a full boot.
I stand corrected. It's not something I've run into, because I habitually use syntax that I know will port easily. (e.g. Defining all the method variables at the beginning of the body.)
As to Kai and Comeau, I can't say as I've never used them.
Yes, GCC 2.95.2 is closer to the C++ standards than several commercial compilers. The last release of the xlC compiler on AIX I used didn't have proper support for templates, and the Sun Workshop compilers had some issues as well.
I really hate to admit it, but the only compiler that seems to implement full support of C++ (including namespaces, templates, et. al.) is MSVC 6. Unfortunately that comes at the cost of being platform specific, and several of the POSIX APIs only implement the minimal spec (e.g. minimal support for NLS, though clearly the platform could handle it -- you have to use platform-specific APIs that have few changes other than the function/method name.)
As to P4 optimization, who cares right now? Until they ramp up the clock speed and drop the price significantly, you get far better bang for the buck with an Athlon/Thunderbird or with dual PIIIs. By the time P4 is worth buying, I'm sure GCC will be doing a pretty good job with the optimization.
As to Borland's compilers, they're good, but I haven't actually used them much. I know how to make things work with MSVC and have current copies of both compilers; I'd rather spend my learning time playing with new kits (qt, kde, gnome, bonobo, etc.) than learning how to make another compiler turn the same code into executables.
Among the key vendors mentioned in the article are IBM and Compaq, both of whom have commercial Unix products. If they aren't happy with the speed that Linus is approving features, they could always publish the full source for AIX and Tru64.
By using LGPL instead of GPL for the source, they'd be free to continue retailing it to their commercial clients. Heck, they could even use a modified LGPL that forbids making the code GPL if they're really paranoid about it getting "infected" by the GPL.
My personal feeling on a "committee" running the Linux kernel is that it's the quickest way to produce another OSF 1 system. Remember that debacle? Thousands of hours between various Unix vendors to produce a "common" system, and the only company to ever ship a release was DEC (now Compaq.)
Design by committee is always less efficient and inelegant due to the politics involved. At least Linus, Alan, and the dozens (hundreds) of contributors to Linux work together, even if they don't agree at times. No one would ever make the same claim for any of the "partnership" corporations, most of which end up disolving a few years later.
They could also always look at alternate kernels, like GNU Hurd, or starting their own "clean" kernel.
To me the final proof of how good a job Linus is doing is IBM's activity. If Linus is doing such a terrible job, why is IBM sinking so much money and effort into the community? Why did they port the kernel to S390 if it was so "terrible" with Linus at the helm?
There are tech related jobs like help desk, system support (tape monkey), wiring infrastructure (cable monkey), and the like which might benefit from a union.
There is a tremendous need for the "Steady Eddie" programmer as well -- the people who prefer a 9-to-5 job monitoring and maintaining existing systems; people who don't love their job, but do it for the paycheck and stability. I could understand them finding some appeal to a union, as they are typically not as well paid as other programmers in the industry.
The developers who get "used" by fly-by-night dot-coms and soon-to-go-public companies allow themselves to be used. They're naively chasing a dream that they're going to win some magic IPO lottery, because a few hundred other people in the industry have.
Take a look at the serious professional, and you're far more likely to find someone who has the experience and confidence to say "no" to the unreasonable demands. They're also the people who will present a reasoned, thoughtful explanation of why a schedule is unreasonable, and provide proposals that are reasonable.
Companies and organizations that want to compete in the IT field want the professionals to lead the teams, and a bunch of regular programmers to implement those visions. They want people who are self motivated, self-training, and realistic.
What the industry doesn't need is a skirt for the incompetant to hide behind, nor a mass of average replacable workers who think they "deserve" an unreasonable wage because they've "got experience."
I deal with far too many people already who think that experience relates to their years in the workforce. You can spend ten years working with the same tech and the same tools, and still be inexperienced. All those years won't help you worth squat when that market dries up and you need to shift gears.
I'm far more interested in working with people who are willing to learn on their own, try different tools and technology, and who can see how those alternate viewpoints relate to their job. I like working with the creative code artists who see the commonality and similarity of diverse systems, who do perverse things like use compiler techniques for parsing data files.
Those are not the goals of a union. The union wants everyone to fit in cookie-cutter categories and salary bands. They want pay for years of service, not for breadth and depth of useful experience. And most of all, the union wants their cut of your paycheck.
Unionize IT? Ttthhhpppttt!!! The very idea comes from the same lawyer-driven camps as software patents.
Still waiting for Alan Kay's vision
on
Digital Doodling
·
· Score: 2
It's been over 20 years since Alan Kay envisioned a notebook sized computer that did windowing and handwriting/pen support, and we *still* haven't achieved that.
A lot of people have made some disparaging remarks about the usefulness of such a device, but for certain tasks it would be a lot easier to use than a keyboard/mouse combo.
For example, scratch diagrams (be they architectural, machine modelling, or data/object modelling.) Right now we have to click the tool. Drag-size the object. Click the entry field. Type text. Repeat, repeat, repeat. Very cumbersome, especially if you're a touch typist who doesn't like to reach for the mouse.
A pad, OTOH, could recognize object shapes and avoid the tool click in the first place. It's easy enough to sketch trapezoids, boxes, squares, etc. on a whiteboard or notepad when doing object design with cohorts. Wouldn't it be handy if those initial notes were directly input as the initial design?
Someone mentioned interviews as one of the situations where you don't want to be tapping at a keyboard. How about meetings? Ever tried to take notes using Palm's stuff in a meeting? Maybe others are quicker at their glyphs, but I just can't write and rewrite in the same spot naturally.
Doing a straight digital capture for the initial data is actually pretty flexible. Once you've got your digital notes, you could use OCR tools on the "image" files, the same as if you'd scanned a document. Even if accuracy isn't too great, you have your raw notes to do corrections from (and no one to blame if you can't read your own writing. *g*)
My bigger concerns are:
Price. $3000 USD is way too much for a PIII600 laptop.
Reduced screen size. Why reduce the screen size? Why not add depth instead and either hinge or clip the notepad portion to the laptop? If clipped, use a reasonable length connector cord or IR -- that way you could leave the laptop on the meeting table and keep the notepad comfortably in your lap.
Special model. Given a clip-on approach, why not just make it a general IR, USB, or PCMCIA device that could clip to any laptop? Use a decent titanium or other durable backing with a more durable surface than the Palm, maybe LCD direct feedback, and you can eliminate the paper completely.
But hey, what do I know? I just work with and program these damn machines, I don't get to make design decisions. That's left up to the sales reps and marketing gurus who couldn't sell great products like OS/2 or the Amiga...
Actually, when Apple (the computer company) started, they apparently were approached by Apple Records over trademark infringement. The computer company agreed that they would not be in the music/audio business, and were not going to enter into such business.
I've often wondered if that might be why their machines have such weak sound support built in...
However, in practicality I'd be much more comfortable with providing such extensions through a mach-like microkernel that keeps the core system functionality of the kernel clean (i.e. following traditional goals.)
Take a look at the number of defects that crop up with seasoned and well maintained TP monitors (Encina, Tuxedo/BEA), databases (Sybase, DB/2, Oracle, etc.), and with various network messaging and remote object services. I don't know about you, but I find the thought that such complex defect-prone software being part of the core kernel disturbing.
Right now if your ORB gets some variant on a DOS attack (say someone repeatedly sending bad or invalid requests), you can shut down that service module in the ORB. What happens when the ORB itself is part of the kernel and the entire kernel is getting beaten to death?
Perhaps there are solutions to these types of issues. Maybe kernel ORBs will be part of the future of computing. Traditionalist that I am, I'll always consider them a system service, rather than an OS service.
It's time a few people out there read up on the goal and purpose of the O/S. The O/S is responsible for process management and scheduling, resource management and sharing, low-level security checking (process-->user/group mapping), and isolating program interaction to safe APIs.
There isn't really anything wrong with writing kernel modules in order to support appliances. It's probably going to be one of the biggest benefits of the Linux kernel architecture, but that doesn't mean modules like khttpd or ORBit should be part of the main kernel distribution.
If you know what you're doing and want to build a custom appliance (e.g. super fast web server), you can add in the modules you need. But by no means should this stuff be part of the standard kernel -- that just starts to smell way too much like Microsoft's "design", with all of the resulting interdependance and patch bloat.
And before you start claiming that you need the performance boost, take a look at how much it would cost to upgrade your CPU, add more memory, or otherwise boost your system. Is it really worth risking system stability to save those few dollars? If you need that kind of performance, aren't you probably in a commercial environment that can afford the hardware?
The author of the article was right about not hearing much about Java from the Linux developers, and that support isn't embedded. Personally I don't think it *should* be embedded. The beauty of the *nix systems is their modularity, not their inbreeding and tendrils of interdependence, ala WinXX.
Working for commercial shops, I can tell you from personal experience there is nothing more painful than trying to select a "common denominator" version of OS, JVM, Webserver, EJB server, and database servers, not to mention third-party products and TP monitors. If it weren't possible to modularize the support, it would be *impossible* to deploy production systems.
As a simple example, current EJB, JSP, and Servlets require JDK 1.2+. The web reporting tools we use only run with JDK 1.1.7+ (not 1.2.) If I were trying to deploy a production environment on NT systems, I'd have no choice but to use two boxes, because you can only have one system JVM. With *nix, I am not cursed by that restriction -- each tool just sets the PATH, LD_LIBRARY_PATH, and CLASSPATH to the versions it needs to run properly.
Our production systems aren't running Linux, but many developer boxes are. You won't see my cohorts out on the net raging about how great Java and Linux are together -- we're too busy working on serving our clients needs to bother arguing with the GPL fanatics.
In 1985/86 my 400 series VLSI design course at university involved leading and trailing clock edge triggers (rising/falling signals.) The use of both edges to effectively double performance was a standard practice, and documented in the textbooks that were printed even earlier.
The rather extreme efforts of Cray Research to balance signal paths in order to allow increased clock speed without loss of signal coherency was also studied.
I don't see anything in the Rambus patent descriptions that don't fall back to common design techniques in use over 10 years ago.
I don't get it. Why isn't Rambus in court on charges of theft or fraud? They claim ownership of design principles that are not only normal practice, but that were created over a decade before their company existed!
None of the places I have worked would accept installing unauthorized software in their networks. It isn't an issue of NT vs. Linux vs. FreeBSD vs. whatever -- it's an issue of maintainability and security.
If you're in a small shop (less than 20 people), they often don't have the staff to maintain more than one OS. If you're in a large shop, there is a major issue of investment, repairability, tracability and responsibility. Sure I could install, admin, and maintain my own desktop Linux box -- I have a couple at home. But that isn't what the company/client pays me for. And who is going to pay for the reinstall of the system after I'm finished a contract?
Don't get me wrong -- I think Linux is great. I'd love to see WinXX and it's instabilities disappear. But that isn't my decision to make. This is up to the people responsible for the systems infrastructure.
That said, not one of the places I have worked has ever refused to let me install an alternative OS or software package, but I justify my request. That isn't to say I always get what I want -- there have been many times where sound business reasons have been given for not following my recommendation or request. Whether I agree or not, the final decision is up to the people responsible for the equipment, not some rogue employee who doesn't like the answer (s)he got.
Would you be surprised if you were fired for installing a virus? For putting untested code on a production system? What about replacing hardware because you weren't happy with your video card/modem/monitor/whatever? Then why would you be surprised to be fired for reformatting the whole system?
Bottom line is if you don't own the equipment and you don't have authorization to modify it or the software, you have no cause to complain if you get fired for going rogue.
I have an issue with your last paragraph. The problem with vinyl isn't the dynamics, but the flakiness and cost of the setup. Take a Sota Star Saphire turntable with an SME IV arm and a Koetsu Black cartridge. When tweaked and "dialed in" the sound stage, imaging, and sibilance of cymbals and brass puts you "there" in the audience.
Unfortunately, it is only "dialed in" for that side of the album you set it for. As soon as you flip the record or change to another one, you need to tweak the setup process again to get that glorious sound. At 10-20 minutes per setup, you end up spending more time tweaking the setup than listening to music.
Does it sound better than even the latest CD players? You bet! But the front end described above use to run about $10-20,000 CDN (depending how you shopped around), and CDs don't require all the fiddling.
Personally I doubt any human will hear a true difference between a top-quality SACD and ADVD format media. They will probably hear a difference between the quality of the line amps (IC vs discrete), power supplies (seperate digital/analog vs single), and quality of the DACs involved.
Personally I'm going to hold off for a year to see which format takes hold in the market, then do some shopping. Either way, I can't wait to have albums that have snares, cymbals, and brass again instead of sounding like I have cotton in my ears.
I worked with Nortel (then Northern Telecom) in the 1988-1990 period. They had production systems with Mac, Win3.1, and Unix/X11 front ends to RPC and TP based middleware. Not that I have any application or contact names, but there is no doubt the technology was already in use.
Business/database computing classes also described such technologies when I was in university a couple years prior to that. Odds are there are some published research papers that not only describe the concept, but compare different implementations for performance.
You also might want to check out IBMs patent database. Most of the n-tier technology concepts were the result of research originally targetted at scaling mainframe applications, including departmental FEPs (front-end processors, a specialized form of middleware.) The fact that X11 provides the display instead of a terminal or PC should be irrelevant.
I have a similar issue, but in order to avoid any gray areas I do all the updates/enhancements at home and email them to work. If I find bugs at work, I email notes about them to put in the code stream, but the main development is always on my own time and hardware to avoid contention.
For the most part I agree, but I came away from the article puzzled as to why the overall ratings for file server and network performance were so high for Win2K when so much of the article text tried to explain why it wasn't as good as the others.
What disturbed me more were the security topics. Corporate security configured through DCE cell management is cross platform and quite easy to manage once it's set up. It also has the advantage over Microsoft in supporting a full enterprise suite of OS', not just Microsoft. I know that's not part of the base for Linux, but I really don't think the file/print servers are where you want to maintain your corporate security. It's much safer to have it run be dedicated special-purpose DCE/Kerberos nodes, for the same reasons you don't run applications on the corporate firewall box.
Personally I find Netware to be the best for basic services, with a supporting *nix box for business apps. It's also a pretty common combination for a lot of companies.
Sidetrack: I'm surprised the threaded TCP stacks haven't been finished for Linux yet. Weren't they supposed to be out late 1999?
Slashdot Mirror
I've contracted to IBM in the past, working at a number of their locations. I knew many people before, during, and since that period who were employees or contractors at IBM. I also know several people from some of their manufacturing plants.
Not one of them has ever hinted at a "sweatshop" as you claim, nor have I ever seen any news articles alluding to such activities. Their employees are not only well paid, but have excellant benefits, solid training programs, and far more say in how their job is done than most other places I've worked at.
In addition, IBM's support of the development community with their "Personal Developer Edition" software is far better than any other company I can think of. How many other companies will sell you a multi-thousand dollar package for the cost of media and shipping so you can use it for training? Sure it gets them more trained people in the field who know their products, but that benefit doesn't seem to be enough to convince any of the other companies to provide similar services.
IBM is a big company, and I'm sure they have their flaws, but your comments have no relevance to reality that I am aware of. If I'm incorrect, please post some links to netzine articles discussing their "sweatshops."
A themer in the sense of Apple's patent has to be able to change the behavior of the widgets. For example, you might switch the activation button for a spin box between MOUSE1 and MOUSE3, or change URL activation between a MOUSE1 single click and a MOUSE1 double click.
In some cases, the themed widgets might only vaguely resemble each other across themes. One theme might use a common drop-down choice box for selections, another might display a panel of radio buttons. Each performs the same function, but the interface behavior changes.
The Plus Pack, on the other hand, only let you do trivial things like use animated cursors and sounds. The underlying behavior of the widgets didn't change.
I'd also have to question whether Copland is truly Apple's sole invention, and how much actually derives from their partnerships with IBM at that time.
This is an old, old idea that's been used by CGI programmers for a very long time. I'm quite certain there are hundreds, if not thousands, of prior-art examples.
The idea is so basic that it's given a whole 5 minutes in the first couple days of IBM's Websphere Application Server, Advanced Edition courses and associated documentation. It's also discussed in the Sun books on programming JSPs and Servlets.
They don't win because of the law, but because nobody is stupid enough to try to pick a fight with a company whose research budget dwarfs most corporate incomes, that has more lawyers on staff than Microsoft, and that has more backing from the community than any other large corporation.
From that perspective, you're right: they have an implicit "trademark" on the letters. But it's because of clout, not because the law would be on their side. (Ignoring the impact big business has on Congress and legal issues due to the number of voters they employ.)
What I'm having a problem with is that SSH is the acronym for a protocol that has been submitted to standards bodies by the holder of the SSH trademark. By definition anything submitted to the public standards bodies becomes part of the public domain.
Aside from the use of the term in the standards documents, there has been no apparent attempt to stop anyone other than the open source development team from using SSH in the name of their "product." As someone else has pointed out in these threads, trademark defense has to be consistent to be valid.
I'm not sure a trademark on the acronym SSH is valid without being more specific about the design of the trademark. Even IBM's trademarks aren't on the three letters IBM, but on specific color combinations and fonts for their famous corporate logo.
Although I generally don't feel Ylonen is acting in good faith in this matter, I'd rather see us switch to a name like OpenSTN, provided that the documentation submitted to the standards bodies are also updated to use a protocol acronym other than SSH. Whatever acronym is used for the standard is the acronym that should be used by Open???.
I don't agree with comments in this thread that the open source project should have a page crediting and linking the commercial provider's site. If anything, they should be referencing the site and documentation from the standards bodies describing the protocol. Once a standard has been submitted to ISO, ANSI, W3C, or any other such body, it is the standard that becomes important for determining interoperability, not the identity of the originator. Any historical credit for the standard should be referenced by the standards documentation, not by the open source implementation.
However, I don't think one would need to save the entire state of system memory for this to be useful. Aside from embedded systems, consider the possibility of an OS that uses a proper swap system and just makes sure the entire physical memory is written to swap when the system suspends. If the MRAM is sufficient to keep the core kernel state and information about the swap pages, your restart would just need to flag all the physical memory as free pages, with everything currently swapped out. Sure it wouldn't be "instant on", but it would be far closer than I've seen to date.
On the flip side, you could probably do something similar with Linux by putting in a boot patch that checks the swap space for a signature indicating it should reload the memory from the swap space instead of going through a full boot process. You'd still have the usual issues of needing to reset hardware, but it would probably be faster than a full boot.
As to Kai and Comeau, I can't say as I've never used them.
I really hate to admit it, but the only compiler that seems to implement full support of C++ (including namespaces, templates, et. al.) is MSVC 6. Unfortunately that comes at the cost of being platform specific, and several of the POSIX APIs only implement the minimal spec (e.g. minimal support for NLS, though clearly the platform could handle it -- you have to use platform-specific APIs that have few changes other than the function/method name.)
As to P4 optimization, who cares right now? Until they ramp up the clock speed and drop the price significantly, you get far better bang for the buck with an Athlon/Thunderbird or with dual PIIIs. By the time P4 is worth buying, I'm sure GCC will be doing a pretty good job with the optimization.
As to Borland's compilers, they're good, but I haven't actually used them much. I know how to make things work with MSVC and have current copies of both compilers; I'd rather spend my learning time playing with new kits (qt, kde, gnome, bonobo, etc.) than learning how to make another compiler turn the same code into executables.
By using LGPL instead of GPL for the source, they'd be free to continue retailing it to their commercial clients. Heck, they could even use a modified LGPL that forbids making the code GPL if they're really paranoid about it getting "infected" by the GPL.
My personal feeling on a "committee" running the Linux kernel is that it's the quickest way to produce another OSF 1 system. Remember that debacle? Thousands of hours between various Unix vendors to produce a "common" system, and the only company to ever ship a release was DEC (now Compaq.)
Design by committee is always less efficient and inelegant due to the politics involved. At least Linus, Alan, and the dozens (hundreds) of contributors to Linux work together, even if they don't agree at times. No one would ever make the same claim for any of the "partnership" corporations, most of which end up disolving a few years later.
They could also always look at alternate kernels, like GNU Hurd, or starting their own "clean" kernel.
To me the final proof of how good a job Linus is doing is IBM's activity. If Linus is doing such a terrible job, why is IBM sinking so much money and effort into the community? Why did they port the kernel to S390 if it was so "terrible" with Linus at the helm?
There is a tremendous need for the "Steady Eddie" programmer as well -- the people who prefer a 9-to-5 job monitoring and maintaining existing systems; people who don't love their job, but do it for the paycheck and stability. I could understand them finding some appeal to a union, as they are typically not as well paid as other programmers in the industry.
The developers who get "used" by fly-by-night dot-coms and soon-to-go-public companies allow themselves to be used. They're naively chasing a dream that they're going to win some magic IPO lottery, because a few hundred other people in the industry have.
Take a look at the serious professional, and you're far more likely to find someone who has the experience and confidence to say "no" to the unreasonable demands. They're also the people who will present a reasoned, thoughtful explanation of why a schedule is unreasonable, and provide proposals that are reasonable.
Companies and organizations that want to compete in the IT field want the professionals to lead the teams, and a bunch of regular programmers to implement those visions. They want people who are self motivated, self-training, and realistic.
What the industry doesn't need is a skirt for the incompetant to hide behind, nor a mass of average replacable workers who think they "deserve" an unreasonable wage because they've "got experience."
I deal with far too many people already who think that experience relates to their years in the workforce. You can spend ten years working with the same tech and the same tools, and still be inexperienced. All those years won't help you worth squat when that market dries up and you need to shift gears.
I'm far more interested in working with people who are willing to learn on their own, try different tools and technology, and who can see how those alternate viewpoints relate to their job. I like working with the creative code artists who see the commonality and similarity of diverse systems, who do perverse things like use compiler techniques for parsing data files.
Those are not the goals of a union. The union wants everyone to fit in cookie-cutter categories and salary bands. They want pay for years of service, not for breadth and depth of useful experience. And most of all, the union wants their cut of your paycheck.
Unionize IT? Ttthhhpppttt!!! The very idea comes from the same lawyer-driven camps as software patents.
A lot of people have made some disparaging remarks about the usefulness of such a device, but for certain tasks it would be a lot easier to use than a keyboard/mouse combo.
For example, scratch diagrams (be they architectural, machine modelling, or data/object modelling.) Right now we have to click the tool. Drag-size the object. Click the entry field. Type text. Repeat, repeat, repeat. Very cumbersome, especially if you're a touch typist who doesn't like to reach for the mouse.
A pad, OTOH, could recognize object shapes and avoid the tool click in the first place. It's easy enough to sketch trapezoids, boxes, squares, etc. on a whiteboard or notepad when doing object design with cohorts. Wouldn't it be handy if those initial notes were directly input as the initial design?
Someone mentioned interviews as one of the situations where you don't want to be tapping at a keyboard. How about meetings? Ever tried to take notes using Palm's stuff in a meeting? Maybe others are quicker at their glyphs, but I just can't write and rewrite in the same spot naturally.
Doing a straight digital capture for the initial data is actually pretty flexible. Once you've got your digital notes, you could use OCR tools on the "image" files, the same as if you'd scanned a document. Even if accuracy isn't too great, you have your raw notes to do corrections from (and no one to blame if you can't read your own writing. *g*)
My bigger concerns are:
- Price. $3000 USD is way too much for a PIII600 laptop.
- Reduced screen size. Why reduce the screen size? Why not add depth instead and either hinge or clip the notepad portion to the laptop? If clipped, use a reasonable length connector cord or IR -- that way you could leave the laptop on the meeting table and keep the notepad comfortably in your lap.
- Special model. Given a clip-on approach, why not just make it a general IR, USB, or PCMCIA device that could clip to any laptop? Use a decent titanium or other durable backing with a more durable surface than the Palm, maybe LCD direct feedback, and you can eliminate the paper completely.
But hey, what do I know? I just work with and program these damn machines, I don't get to make design decisions. That's left up to the sales reps and marketing gurus who couldn't sell great products like OS/2 or the Amiga...I've often wondered if that might be why their machines have such weak sound support built in...
However, in practicality I'd be much more comfortable with providing such extensions through a mach-like microkernel that keeps the core system functionality of the kernel clean (i.e. following traditional goals.)
Take a look at the number of defects that crop up with seasoned and well maintained TP monitors (Encina, Tuxedo/BEA), databases (Sybase, DB/2, Oracle, etc.), and with various network messaging and remote object services. I don't know about you, but I find the thought that such complex defect-prone software being part of the core kernel disturbing.
Right now if your ORB gets some variant on a DOS attack (say someone repeatedly sending bad or invalid requests), you can shut down that service module in the ORB. What happens when the ORB itself is part of the kernel and the entire kernel is getting beaten to death?
Perhaps there are solutions to these types of issues. Maybe kernel ORBs will be part of the future of computing. Traditionalist that I am, I'll always consider them a system service, rather than an OS service.
There isn't really anything wrong with writing kernel modules in order to support appliances. It's probably going to be one of the biggest benefits of the Linux kernel architecture, but that doesn't mean modules like khttpd or ORBit should be part of the main kernel distribution.
If you know what you're doing and want to build a custom appliance (e.g. super fast web server), you can add in the modules you need. But by no means should this stuff be part of the standard kernel -- that just starts to smell way too much like Microsoft's "design", with all of the resulting interdependance and patch bloat.
And before you start claiming that you need the performance boost, take a look at how much it would cost to upgrade your CPU, add more memory, or otherwise boost your system. Is it really worth risking system stability to save those few dollars? If you need that kind of performance, aren't you probably in a commercial environment that can afford the hardware?
You forgot to mention Borland's JBuilder, which is also an excellant IDE. Cafe is nice, too, if you prefer multi-window IDEs over MDI IDEs.
The great grandfather of IDEs works pretty well, too. (Emacs!)
The author of the article was right about not hearing much about Java from the Linux developers, and that support isn't embedded. Personally I don't think it *should* be embedded. The beauty of the *nix systems is their modularity, not their inbreeding and tendrils of interdependence, ala WinXX.
Working for commercial shops, I can tell you from personal experience there is nothing more painful than trying to select a "common denominator" version of OS, JVM, Webserver, EJB server, and database servers, not to mention third-party products and TP monitors. If it weren't possible to modularize the support, it would be *impossible* to deploy production systems.
As a simple example, current EJB, JSP, and Servlets require JDK 1.2+. The web reporting tools we use only run with JDK 1.1.7+ (not 1.2.) If I were trying to deploy a production environment on NT systems, I'd have no choice but to use two boxes, because you can only have one system JVM. With *nix, I am not cursed by that restriction -- each tool just sets the PATH, LD_LIBRARY_PATH, and CLASSPATH to the versions it needs to run properly.
Our production systems aren't running Linux, but many developer boxes are. You won't see my cohorts out on the net raging about how great Java and Linux are together -- we're too busy working on serving our clients needs to bother arguing with the GPL fanatics.
The rather extreme efforts of Cray Research to balance signal paths in order to allow increased clock speed without loss of signal coherency was also studied.
I don't see anything in the Rambus patent descriptions that don't fall back to common design techniques in use over 10 years ago.
I don't get it. Why isn't Rambus in court on charges of theft or fraud? They claim ownership of design principles that are not only normal practice, but that were created over a decade before their company existed!
If you're in a small shop (less than 20 people), they often don't have the staff to maintain more than one OS. If you're in a large shop, there is a major issue of investment, repairability, tracability and responsibility. Sure I could install, admin, and maintain my own desktop Linux box -- I have a couple at home. But that isn't what the company/client pays me for. And who is going to pay for the reinstall of the system after I'm finished a contract?
Don't get me wrong -- I think Linux is great. I'd love to see WinXX and it's instabilities disappear. But that isn't my decision to make. This is up to the people responsible for the systems infrastructure.
That said, not one of the places I have worked has ever refused to let me install an alternative OS or software package, but I justify my request. That isn't to say I always get what I want -- there have been many times where sound business reasons have been given for not following my recommendation or request. Whether I agree or not, the final decision is up to the people responsible for the equipment, not some rogue employee who doesn't like the answer (s)he got.
Would you be surprised if you were fired for installing a virus? For putting untested code on a production system? What about replacing hardware because you weren't happy with your video card/modem/monitor/whatever? Then why would you be surprised to be fired for reformatting the whole system?
Bottom line is if you don't own the equipment and you don't have authorization to modify it or the software, you have no cause to complain if you get fired for going rogue.
Unfortunately, it is only "dialed in" for that side of the album you set it for. As soon as you flip the record or change to another one, you need to tweak the setup process again to get that glorious sound. At 10-20 minutes per setup, you end up spending more time tweaking the setup than listening to music.
Does it sound better than even the latest CD players? You bet! But the front end described above use to run about $10-20,000 CDN (depending how you shopped around), and CDs don't require all the fiddling.
Personally I doubt any human will hear a true difference between a top-quality SACD and ADVD format media. They will probably hear a difference between the quality of the line amps (IC vs discrete), power supplies (seperate digital/analog vs single), and quality of the DACs involved.
Personally I'm going to hold off for a year to see which format takes hold in the market, then do some shopping. Either way, I can't wait to have albums that have snares, cymbals, and brass again instead of sounding like I have cotton in my ears.
I worked with Nortel (then Northern Telecom) in the 1988-1990 period. They had production systems with Mac, Win3.1, and Unix/X11 front ends to RPC and TP based middleware. Not that I have any application or contact names, but there is no doubt the technology was already in use.
Business/database computing classes also described such technologies when I was in university a couple years prior to that. Odds are there are some published research papers that not only describe the concept, but compare different implementations for performance.
You also might want to check out IBMs patent database. Most of the n-tier technology concepts were the result of research originally targetted at scaling mainframe applications, including departmental FEPs (front-end processors, a specialized form of middleware.) The fact that X11 provides the display instead of a terminal or PC should be irrelevant.
A minidisc essentially is a mini rewritable CD. Though they look like them, they are not floppies!
I have a similar issue, but in order to avoid any gray areas I do all the updates/enhancements at home and email them to work. If I find bugs at work, I email notes about them to put in the code stream, but the main development is always on my own time and hardware to avoid contention.
AEVV provided hours of entertainment in my high school and University days.
God bless and go in peace, A. E.
For the most part I agree, but I came away from the article puzzled as to why the overall ratings for file server and network performance were so high for Win2K when so much of the article text tried to explain why it wasn't as good as the others.
What disturbed me more were the security topics. Corporate security configured through DCE cell management is cross platform and quite easy to manage once it's set up. It also has the advantage over Microsoft in supporting a full enterprise suite of OS', not just Microsoft. I know that's not part of the base for Linux, but I really don't think the file/print servers are where you want to maintain your corporate security. It's much safer to have it run be dedicated special-purpose DCE/Kerberos nodes, for the same reasons you don't run applications on the corporate firewall box.
Personally I find Netware to be the best for basic services, with a supporting *nix box for business apps. It's also a pretty common combination for a lot of companies.
Sidetrack: I'm surprised the threaded TCP stacks haven't been finished for Linux yet. Weren't they supposed to be out late 1999?