There was a cap of 195,000 H1B Visas; in October of 2003 (after the "dot bomb"), this was dropped to 65,000.
As of about June of this year, an additional 20,000 have been allocated, but so far very few people are actually filing for these additional Visas: the US is no longer seen as such a desirable place to work, after all.
Note that the H1B criteria for these Visas is an MS from a U.S. school, or a BS and 5 years work experience prior to the filing.
This one's a little out of date regarding what actually happened: the article headline claims "U.S. Expects 20,000 H1B Visas To Go Quickly", but in fact hardly any of them have gone anywhere.
I think the real issue here is that during the "dot com gold rush", a lot of U.S. students left college before graduating, or graduated with a BS and left for the money, to be a warm body in a V.C.-funded cubicle far, and didn't pursue a post-graduate degree.
From that perspective, Mr. Gates is right: there's a serious lack of available talent; if an MS is the same as a BS + 5 years experience, then many of the people who at least got their BS still have ~2 years on average to "ripen".
Another problem, more or less one he brought on himself, is that it's a common Microsoft practice to get students fresh out of graduating college, and make them over in their own image. From that perspective, Mr. Gates is also right, that there's a serious lack of available talent - that he's willling to hire. The issue here is more complicated, but it boils down to to the staza from the song about social unrest in Algerian Muslims, post WWI: "How are you going to keep them down on the farm, once they've seen Paree?". Working 5 years in the real world would probably sour someone on working for Microsoft at an entry level position.
It's an untenable position to be sure, but it's mostly of his own making.
20? What are the elimination criteria for the vehicles DARPA's simply not going to let compete?
Specifically, if no one has ever done this successfully before, how the heck do they know what a successful approach looks like?
I understand dropping the obvious non-starters - teams whose vehicles crash or get lost on a small test course, or teams whose vehicles are not ready to go at all - both of these are valid rejection criteria.
But it seems really silly to set an abitrary number at "exactly 20"; the article doesn't really explain how the decision on whether or not your vehicle "makes the cut", other than "was evaluated by DARPA experts" - who have yet to solve the problem themselves.
Easy: it's using a technological means to collect personally identifiable information about you.
I've often thought that engineers have a moral responsibility to not work on certain technologies that can be easily used to subvert a persons constitutional rights. Luckily for the bad guys, there are immoral engineers.
"[...GPL code relicensing can become impossible...] That really depends on whether or not you just accept random patches, or if you're planning to license the code commercially, whether you require copyright assignment to you before applying those patches."
What this really depends on is how long you are willing to enforce this copyright assignment policy before someone forks your GPL'ed version of your product, and starts accepting the patches that you won't, without the assignment. Patches you will be unable to integrate yourself, without committing you to not commercially licensing the code yourself, in the future.
Then watch how quickly you get left in the dust with your relicense-able-but-hopelessly-out-of-date code base.
There's no room for dual licensing in code; code contributed back under the auspices of one license quickly becomes unusable under the other.
And GPL-license-using-folks can't see past the current state of affairs in the software industry, and thus assume that we actually need anything other than public domain software to begin with.
The BSD license is as close to public domain as you can legally get in this litigous society, which would not protect a public domain software author from liability for damages caused by their software.
The GPL exists because copyright on software exists, and because it depends on copyright for software, it perpetuates the idea that intellectual property protection for software - both copyright and patents - should continue to exist so that it can force source availability through license that uses copyright for enforcement.
Say we disbanded copyright for software tomorrow, but continued to permit liability disclaimers - then where would GPL be? That's right - it'd be just another BSD license.
People who add GPL to useful code prop up the existing copyright structure that RMS's "GNU Manifesto" claims to decry.
IBM bought Whistle Communications, which built an embedded system based on FreeBSD.
Subsequent to the purchase by IBM, I, Julian Elisher, Archie Cobbs, and others at the new "IBM GSB" were permitted and encouraged to continue contributing code back to the FreeBSD project.
Interestingly, the two problems they had during due dilligence were PHK's "Beerware" license on a FreeBSD kernel file, and our use in the upcoming release of a GPL'ed project that ran in user space and violated 6 of IBM's patents. The "Beerware" issue was resolved quickly, but we were forced to rip out the GPL'ed project and replace it with an equivalent that was under a BSD license instead.
What IBM says publically about Linux, and what IBM requires in the two week course it makes it's employees take before allowing them to work with GPL'ed code, are two different things.
Do they realize the IBM patents they're now using?
I worked at a company that was acquired by IBM (Whistle Communications). During the acquisition, the product currently under development used an Open Source package as a non-integrated, but essential component.
In order to close the deal and sell the company to IBM, we had to remove that package from the product under development because IBM knew it infringed four IBM patents, and if we were to ship a GPL'ed product based on that code, then after the acquisition, IBM would be knowingly granting royalty free licenses to use those patents (under U.S. Commerce rules, anyone else could then use the patents for the same fee, or a lesser fee, if a lesser one was negotiated).
The "real" Microsoft Office Professional has: o Access o Excel o Outlook o PowerPoint o Publisher o Word
Even if Apple does a spreadsheet, that's not going to be enough. The major deployment for Office in small to medium businesses is with MS Access and a bunch of Visual BASIC/VBScript glue to turn it into vertical market custom software.
I know several people who run multimillion dollar financial services businesses, each of which is under 100 employees, and their collections applications, reporting applications, etc., are all based on this model to glue things together.
If you try to buy discounted paper - e.g. you are into factor financing, or you are dealing with a Fannie May or Freddie Mac paper, or subprime credit (face it: that's most of the people trying to get credit in the first place), etc. - then you are likely in this category. Even if you aren't, the data comes from companies like Credit Suisse First Boston, Chase Manhattan, Banc Of America, etc., on CDROMs in access database or Excel spreadsheet data formats.
The thing that would switch these people over to Macintosh (don't kid yourself, many of these people want to switch - their employees are just as likely as the next huys to surf the web and end up with spyware out the wazoo) is the ability to run all the same scripts and custom code (all of it interpreted) as they can on their Windows workstation. I know at least three companies that would switch in an instant, but who aren't willing to do so now because they don't want to have to invest in something they can't make minor changes to themselves without learning how to be a programmer. Or keeping a programmer on staff full time.
And that's just one vertical market.
You can find the same issues with document storage and retrieval systems that use optical scanning to get out from under paper. You can also find the same thing with medical billing systems, and Doctors office management systems. Many insurance companies have specific client requirements for integration with their networks for electronic billing and payment processing: if you don't do it using their app., then you get to fill out paper, and they get to it when they get to it.
The deck is seriously stacked, and it's the compatibility of the database and the inter-application scripting, not the spreadsheets, which keeps Windows entrenched. It's no mistake that neither Access or the full VisualBASIC suite has made it to platforms other than Windows.
-- Terry
And if you add up the other domains Earthlink owns
on
Zombie Report By ISP
·
· Score: 2, Interesting
And if you add up the other domains Earthlink owns, it's even higher in the list...
R&D Costs for driver development can't be recouped
When BusLogic came out with their AHA1540/AQHA1542 compatible SCSI controllers, they did several things:
(1) They leveraged Adaptec's R&D effort on driver development so that they didn't have to spend their own money developing drivers.
(2) They avoid the effort of convincing Microsoft to ship with the drivers as part of Windows; never underestimate the barrier to entry a separate driver disk represents: for NT 3.51, you had to install the driver disk twice during the installation process, and a third time post-install to use a third party disk controller, and it was not well documented where or when NT 3.51 would reference the disk, not find it, and simply crash (you "just had to know").
(3) By making the card's interface compatible with an existing card, they avoided all the R&D necessary to get from a concept to a working interface.
So basically, BusLogic got a free ride on Adaptec's dime in a number of areas, and Adaptec was left holding the bag, having to charge a higher amount to recoup their R&D investment, leaving BusLogic to undercut their prices and steal their market.
That's not to say that I totally agree with Adaptec, or that bad designs which can't be safely exposed without risking physical damage to the devices (Diamond Multimedia video cards[*]) or legal repercussions (Oscillator/PLL tuned WiFi cards that don't have hard-wired frequency bands) don't exist, but I can certainly understand the position of companies who don't want to sacrifice hard-earned product lead-times, OS vendor relationships, or actual R&D results on the altar of public domain.
[*] Diamond, in particular, pisses me off, since any halfway decent software engineer could have separated the model and view from the controller, and made their cards both Open Source friendly and non-x86 architecture friendly, and the EE who wrote the firmware didn't.
If Intel is an 800lb gorilla, Microsoft is 1600lbs
Intel's ACPI reference implementation doesn't work with a lot of hardware, despite great efforts being made by both Intel and FreeBSD, all the vendors code their ACPI implementations to the point that they work with the Windows ACPI implementation (not derived from Intel's reference), and no farther.
If Intel had the power in the market that you're claiming for it, then all boards out there would work with the ACPI reference implementation, and FreeBSD and Linux would have far fewer headaches.
CA Bottle deposit laws are broken at reclaimation; sure, there's a "CA redemption value" printed on all the plastic bottles -- but when was the last time you saw a redemption center at your local Safeway/Albertsons/Thrifty/Longs/Red Owl/whatever?
I forsee the same problem for any "deposit" law for computer equipment or tennis shoes or whatever.
Putting a deposit on the thing that you reclaim when something is disposed of properly only works if you provide a location where things can be disposed of properly.
As far as I can tell, nobody ever reclaims these things because it's practically impossible, and concientious people end up paying the non-refundable "deposit", and then paying again to have their recyling hauled away to a recyling plant.
Ugh... default return key bindings suck. I also meant ot say:
"...showed that a single atom on a silicon surface can be controllably charged..."
This seems to me that it would take a heck of a lot of shielding, or a lot of redundancy, to prevent accidental state changes interfering with the operation of a device based on such components.
You mean to say that "it's morally wrong", not "it's ethically wrong".
Ethics have to do with personal principles; morals have to do with societal principles.
Morals: Of or concerned with the judgment of the goodness or badness of human action and character.
Ethics: the principles of conduct governing an individual or a profession.
People get confused about this because they hear terms like "medical ethics" or "legal ethics", which really refer to the morals espoused by a specific subset of society, a profession.
It's pretty much impossible to act against one's own ethics: they rule how you act.
Morals are pretty much enforced by society: individuals act morally either because their personal ethical system is in alignment with the general idea of what constitutes moral behaviour, or they do so out of fear of punishment by the society in which a given act would be (a) perceived to be immoral, and (b) the extent to which that society is able to enforce its morals by punishment of those who do not act in accordance with them.
Now that we have that out of the way, lets look and see if it's really "morally wrong", or if you're just expressing your opinion.
The answer to that question, as to whether or not the larger society, in fact, views the act as immoral, ultimately depends on whether or not your opinion represents a majority.
The issue here is whether or not the existing laws were paid for by special interests, or were enacted to impose the will of the majority on the rest of society. If the latter, then yes, it was immoral. But if the former... then the law will not be upheld in court (jury nullification), or awarded damages will be token rather than punative (e.g. $1), and the act is not in fact immoral.
I think if you were to take a poll here, you would find that the majority of *this* society, Slashdot, do not find the act immoral.
I also think that if you investigate further, neither does the larger society believe the act immoral, particularly given the inflation of ticket prices.
Actually, it's a flaw in the ATA specification: ATA drives can do a disconnected read, but there is no way to do a disconnected write.
Because of this, you can have a tagged command queue for read operations, but there is no way to provide a corresponding one for write operations.
SCSI does not have this limitation, but the bus implementation is much more heavyweight, and therefore more expensive.
The problem is exacerbated, in that ATA does not permit new disconnected read requests to be issues while the non-diconnected write request is outstanding. Therefore, any write acts as a read stall barrier.
In order to compete with SCSI on both write performance, and interleaved read/write operation performance, manufacturers added write caching by default, breaking the historical contract about when a write completes to stable storage vs. the write operation not returning until it did.
Today, there are still a number of disks that *actually* lie, and there are a number of firewire/ATA bridge chipsets that do not propagate the FW sync into an ATA sync, even if you didn't end up with a disk that lied.
So you can be screwed if:
1) The disk lies about honoring the cache flush request (there was one series of Quantum ATA disks that did this, for which Quantum promptly provided a firmware update. I really like Quantum for this, and you can find the discussion on the FreeBSD-hackers mailing list archives).
2) The controller or bridge chipset responds to the flush request, but does not propagate it to the actual devices (there is one popular bridge chip that does this; since it was not recalled by the manufacturer, and there is no firmware update fix possible, in the interests of not being sued, I'm going to avoid naming names here.
3) The OS may not issue the command for user perceived peroformance reasons relative to the competition (this is why, before the cache flush command existed in the ATA specification, FreeBSD turned back on the write cache by default, even though everyone knew that data integrity guarantees *would* go out the window).
Unfortunately, I can no longer just say "ATA sucks; use SCSI", because a number of SCSI disk manufacturers have started doing the same pig tricks with their SCSI disks (again, not naming names), and ignore the SCSI cache flush command, or ignore the mode page setting for synchronous I/O completion with tagged write commands (writing is slow, especially if you have to read an entire track to write a block).
Hopefully, this Slashdot article will cause the mainstream press to put enough light on this issue to shame the drive manufacturers into at least labelling actually compliant drives.
-- Terry
Secure in the second place is no good...
on
Hack IIS6 Contest
·
· Score: 1
Rather than finding and plugging holes in IIS, we could achieve the desired ends of "safer sites across the board" by having them install something other than IIS.
In other words, using "secure in the first place" software, instead of trying to make "insecure in the first place" software into "secure in the second place" software.
Any "secure in the second place" software still suffers from the top security problem out there: people who don't update their insecure software when patches become available.
Without patching the fact that people don't patch things, you haven't solved anything. The only way to solve *that* problem is to have forced upgrades *or* to have software that doesn't require upgrading for it to be secure.
People complaining about server installs and power user installs shouldn't use this: they are not the target market, and they should quit complaining and simply not use it: no loss.
Complaining about the desktop choice is another self-defeating proposition: he had to pick *something*, and it had to be one thing to start with, not "pick one of 1000". It also has the benefit of giving a platform target ABI to developers who want to do desktop applications: one of the biggest reasons UNIX systems don't end up with a lot of applications is lack of a uniform target ABI. Even if the API was the same across multiple look-and-feel values, it's not enough to attract developers: requiring a recompilation means doubling their support and testing burdens, as well as their SKU count (if they don't ship all versions on the same CD/DVD).
One of the best things MacOS X did, from this perspective, is *not* open up the GUI code, so that people have a hard time making a zillion incompatible versions and shipping them around, fragmenting the market. I hope he does not cave in to pressure to "pull a RedHat" with a "KDE or Gnome" option.
For the average user, it's a step in the right direction, and one that all of the BSD's, save MacOS X, have been too snobby to take on their own (or too caught up in the myth of the server being the only market space that's a valid target for a BSD based OS).
There are a couple of things that could be changed to make it better, but it's miles above the fear-inspiring raw text prompt and ASCII graphics of the normal FreeBSD installer.
Instead of a hierarchical relationship between things you have to fill out, as in sysinstall, where it's an exercise for the student to traverse the installation/configuration tree, it's a simple linear progression.
Instead of dropping you to a raw login prompt, it drops you to a KDE login.
All in all, it removes much of the "fear barrier" that keeps people from even considering installing a BSD operating system on their machine in the first place.
I dislike the use of the GPL, but given that it's written against a GPL'ed toolkit, it's excusable in the face of what it provides.
Here's what else I think it needs to really polish it off:
o Graphical partition editor
It currently assumes you have a free partition lying around, and it doesn't really permit editing it. I know this is a very hard nut to crack, and that Partition Magic has an entire product dedicated to the task (AFAIK, it's the only product that can safely resize NTFS partitions); I'm not sure how doable this is, but it's near the top of the list.
NB: The only reasonably way I have ever come up with to deal with this, short of contracting the work out the the P.M. people, is a Window NT install program that allocated a chunk of disk space *inside* the NTFS, and then a booter program that is an icon on the NT desktop, and let FreeBSD use the existing allocated NTFS file as a fielsystem, after hacking the block driver to make it appear virtually contiguous. I expect that this will be the last thing on my list implemented, if ever.
o Creation of an "admin" account, rather than root
This would just be the initial user's account, with rights to "sudo"; they could name it anything they wanted to name it. The root account would be disabled by default; you could always enable it via "sudo passwd" later, if you wanted to be able to login as root instead of the user.
o Automatic walk-through for the configuration
If you have an initial account other than the root account, you can walk the user immediately through the account-specific configuration. This would be a smoother transition, rather than stopping, requiring a login, and then continuing.
o Automatic login as the admin user
I realize that this may seem much less anal than a typical UNIX appraoch to things, but it's possible to do this relatively safely, simpy by enabling a screen saver
It's close to a "Mini-LSB"; it's unfortunate that it doesn't address the ability to turn off all interfaces not in the standard to trigger compile time errors in non-binary-compatible code. 8-(.
I still think there would be a great deal of resistance to this sort of thing for the reasons cited in my initial post; it would probably take an "artistic license"-style license change to enforce compliance with something like this across vendors.
I don't think that's something we are likely to see happen, given the huge backlash against things like SCSL.
There are a couple of posts that get part of the answer to the question being asked and none of them has been moderated to higher than a 3 (and that one was somewhat off topic).
A few years back, I tried to do something similar to what a part of what LSB attempts to do, and it was like pulling teeth to get anyone to even talk about it. The initive was called FABIO, for "Free Application Binary Interface Objective". The intent was to get all the x86 Linux and BSD distributions to sync up with a single ABI, hopefully derived from a commercial ABI - the front-runner at the time, by far, was Solaris.
Nobody would do it, and it's for the same reasons that FABIO was stillborn, and the LSB is significantly more far-reaching than FABIO ever was:
1) Loss of editorial control
This is a big one for some projects. What if the LSB suddenly includes a library with a license that Debian can't live with, for example? What if I'm building an enterprise version of Linux, and I don't *want* to include graphics drivers that are part of the LSB 3.x specification? This is much less about what to put where as it is about what to include or not include in a distribution, and the acceptable per-distribution licensing policies and practices. The LSB throws in the kitchen sink.
2) Commoditization
If everyone conforms to a standard, what differentiates one product from another? This was touched on in that other posting. So far, no one has used the phrase "UNIX Wars", so I will. The UNIX Wars were about product differentiation. The other posting suggested that this was a result of market forces toward stratification, where different products rise up to meet different sets of needs. This is incorrect. FABIO only intended to standardize ABI - far less than the ambitious LSB. Further, it wanted to pick an existing commercial UNIX to standardize against, and finally, it wanted to define two levels of compliance. In the lowest level, you would be guaranteed that the standardized APIs were present. In the highest leve, you were able to turn off all APIs which were not standard: a guarantee that you could write code without unwittingly using a vendor extension, making the resulting binary non-portable. A mass exodus of developers to level 1 compliant platforms (to obtain the largest possible market) was expected... *if* FABIO made it. Neither the Linux nor the BSD camps bought into the idea: it would have rendered them commodities, differentiated only by philosophy and license. This is the same thing that drove the UNIX Wars: "I can't/won't compete against Microsoft, so I'll drive this other UNIX vendor out of business and take his market instead".
3) It's too big to be meaningful in any real sense
The LSB is too big to implement everything, and if you don't implement everything, you aren't LSB compliant. Face it, it's a superset of POSIX, and there's not one Linux yet that can claim full POSIX conformance for their system, let alone add in the other parts of the specification to get to LSB conformance. It's too damn big, and you can't turn off those things that are optional (you can barely do this with POSIX, using unistd.h, and if you do that with too many things, your system is useless anyway:. There's no agreed upon mandatory subset that lets you turn off the non-mandatory parts, and not get them at all, and know that all other mandatory compliance is there. POSIX has this problem in spades; the unistd.h mechanism is really poor at letting you pick interfaces to *NOT* be there: you can't. You also can't know, without a lot of research, what things are mandatory for conformance with standards built on top of POSIX - this is left as an exercise for the developer, who can say "if this interface is there, use it", but can't go anywhere and ask "what interfaces can I safely use, always, as long as a platform is conformant with standard XXX?". The LSB does a worse job: it includes POSIX, and then adds things on top of
Its latest survey, published on Monday, reported that Microsoft Windows Server 2003 is at least as good if not better than Linux, in terms of quality, performance and reliability.
I guess compromised servers are just as reliable as uncompromised ones?
Full Disclosure: I'm a Senior Associate with the Institute for Molecular Manufacturing http://imm.org/.
I have to say that this article seriously misses the mark.
Recombinant DNA research self-regulation has been in place for 30 years now, and it has worked very well to prevent "Andromeda Strain" style accidents. The most recent full overhaul was in 1994:
There are people who are holding debates about similar regulation for molecular nanotechnology already: The National Nanotechnology Initiative http://www.nano.gov/, The Foresight Institute http://foresight.org/, The International Council on Nanotechnology http://icon.rice.edu/, and many others, including the IMM. The intent of these organizations is to establish guidelines for developement of nanotechnology, and to explore applications.
Here is the first set of guidelines which have been established:
Don't blow things out of proportion until they are actually implemented; the amount of regulation of any technology has historically always been as much or even much more than was necessary at the time.
As a special case, you can depreciate PC equipment and software over 3 years if it was purchased ina certain date range, or if it's purely a business asset:
I meant Gould. I am absolutely terrible with names.
When I mentioned the references to Scopes, of course it was with regard to the mechanics as they were understood directly from Darwin's writings, which meant his understanding of them.
Pushing a non-scientific position is always all about intentionally picking an already discredited theory as a whipping boy, and then citing the evidence that was used to discredit it.
The H1B Visa situation has been misrepresented.
h ives.jhtml?articleId=163101217
There was a cap of 195,000 H1B Visas; in October of 2003 (after the "dot bomb"), this was dropped to 65,000.
As of about June of this year, an additional 20,000 have been allocated, but so far very few people are actually filing for these additional Visas: the US is no longer seen as such a desirable place to work, after all.
Note that the H1B criteria for these Visas is an MS from a U.S. school, or a BS and 5 years work experience prior to the filing.
Here's a CRN article that also quotes Bill gates:
http://www.crn.com/sections/breakingnews/dailyarc
This one's a little out of date regarding what actually happened: the article headline claims "U.S. Expects 20,000 H1B Visas To Go Quickly", but in fact hardly any of them have gone anywhere.
I think the real issue here is that during the "dot com gold rush", a lot of U.S. students left college before graduating, or graduated with a BS and left for the money, to be a warm body in a V.C.-funded cubicle far, and didn't pursue a post-graduate degree.
From that perspective, Mr. Gates is right: there's a serious lack of available talent; if an MS is the same as a BS + 5 years experience, then many of the people who at least got their BS still have ~2 years on average to "ripen".
Another problem, more or less one he brought on himself, is that it's a common Microsoft practice to get students fresh out of graduating college, and make them over in their own image. From that perspective, Mr. Gates is also right, that there's a serious lack of available talent - that he's willling to hire. The issue here is more complicated, but it boils down to to the staza from the song about social unrest in Algerian Muslims, post WWI: "How are you going to keep them down on the farm, once they've seen Paree?". Working 5 years in the real world would probably sour someone on working for Microsoft at an entry level position.
It's an untenable position to be sure, but it's mostly of his own making.
-- Terry
20? What are the elimination criteria for the vehicles DARPA's simply not going to let compete?
Specifically, if no one has ever done this successfully before, how the heck do they know what a successful approach looks like?
I understand dropping the obvious non-starters - teams whose vehicles crash or get lost on a small test course, or teams whose vehicles are not ready to go at all - both of these are valid rejection criteria.
But it seems really silly to set an abitrary number at "exactly 20"; the article doesn't really explain how the decision on whether or not your vehicle "makes the cut", other than "was evaluated by DARPA experts" - who have yet to solve the problem themselves.
-- Terry
"... how exactly?"
Easy: it's using a technological means to collect personally identifiable information about you.
I've often thought that engineers have a moral responsibility to not work on certain technologies that can be easily used to subvert a persons constitutional rights. Luckily for the bad guys, there are immoral engineers.
-- Terry
Dual licencing is a non-starter. You say:
"[...GPL code relicensing can become impossible...] That really depends on whether or not you just accept random patches, or if you're planning to license the code commercially, whether you require copyright assignment to you before applying those patches."
What this really depends on is how long you are willing to enforce this copyright assignment policy before someone forks your GPL'ed version of your product, and starts accepting the patches that you won't, without the assignment. Patches you will be unable to integrate yourself, without committing you to not commercially licensing the code yourself, in the future.
Then watch how quickly you get left in the dust with your relicense-able-but-hopelessly-out-of-date code base.
There's no room for dual licensing in code; code contributed back under the auspices of one license quickly becomes unusable under the other.
-- Terry
And GPL-license-using-folks can't see past the current state of affairs in the software industry, and thus assume that we actually need anything other than public domain software to begin with.
The BSD license is as close to public domain as you can legally get in this litigous society, which would not protect a public domain software author from liability for damages caused by their software.
The GPL exists because copyright on software exists, and because it depends on copyright for software, it perpetuates the idea that intellectual property protection for software - both copyright and patents - should continue to exist so that it can force source availability through license that uses copyright for enforcement.
Say we disbanded copyright for software tomorrow, but continued to permit liability disclaimers - then where would GPL be? That's right - it'd be just another BSD license.
People who add GPL to useful code prop up the existing copyright structure that RMS's "GNU Manifesto" claims to decry.
-- Terry
IBM *did* contribute code to FreeBSD
IBM bought Whistle Communications, which built an embedded system based on FreeBSD.
Subsequent to the purchase by IBM, I, Julian Elisher, Archie Cobbs, and others at the new "IBM GSB" were permitted and encouraged to continue contributing code back to the FreeBSD project.
Interestingly, the two problems they had during due dilligence were PHK's "Beerware" license on a FreeBSD kernel file, and our use in the upcoming release of a GPL'ed project that ran in user space and violated 6 of IBM's patents. The "Beerware" issue was resolved quickly, but we were forced to rip out the GPL'ed project and replace it with an equivalent that was under a BSD license instead.
What IBM says publically about Linux, and what IBM requires in the two week course it makes it's employees take before allowing them to work with GPL'ed code, are two different things.
-- Terry
Do they realize the IBM patents they're now using?
I worked at a company that was acquired by IBM (Whistle Communications). During the acquisition, the product currently under development used an Open Source package as a non-integrated, but essential component.
In order to close the deal and sell the company to IBM, we had to remove that package from the product under development because IBM knew it infringed four IBM patents, and if we were to ship a GPL'ed product based on that code, then after the acquisition, IBM would be knowingly granting royalty free licenses to use those patents (under U.S. Commerce rules, anyone else could then use the patents for the same fee, or a lesser fee, if a lesser one was negotiated).
Mr. Foot, meet Mr. Bullet...
-- Terry
Not enough, not comparable.
The "real" Microsoft Office Professional has:
o Access
o Excel
o Outlook
o PowerPoint
o Publisher
o Word
Even if Apple does a spreadsheet, that's not going to be enough. The major deployment for Office in small to medium businesses is with MS Access and a bunch of Visual BASIC/VBScript glue to turn it into vertical market custom software.
I know several people who run multimillion dollar financial services businesses, each of which is under 100 employees, and their collections applications, reporting applications, etc., are all based on this model to glue things together.
If you try to buy discounted paper - e.g. you are into factor financing, or you are dealing with a Fannie May or Freddie Mac paper, or subprime credit (face it: that's most of the people trying to get credit in the first place), etc. - then you are likely in this category. Even if you aren't, the data comes from companies like Credit Suisse First Boston, Chase Manhattan, Banc Of America, etc., on CDROMs in access database or Excel spreadsheet data formats.
The thing that would switch these people over to Macintosh (don't kid yourself, many of these people want to switch - their employees are just as likely as the next huys to surf the web and end up with spyware out the wazoo) is the ability to run all the same scripts and custom code (all of it interpreted) as they can on their Windows workstation. I know at least three companies that would switch in an instant, but who aren't willing to do so now because they don't want to have to invest in something they can't make minor changes to themselves without learning how to be a programmer. Or keeping a programmer on staff full time.
And that's just one vertical market.
You can find the same issues with document storage and retrieval systems that use optical scanning to get out from under paper. You can also find the same thing with medical billing systems, and Doctors office management systems. Many insurance companies have specific client requirements for integration with their networks for electronic billing and payment processing: if you don't do it using their app., then you get to fill out paper, and they get to it when they get to it.
The deck is seriously stacked, and it's the compatibility of the database and the inter-application scripting, not the spreadsheets, which keeps Windows entrenched. It's no mistake that neither Access or the full VisualBASIC suite has made it to platforms other than Windows.
-- Terry
And if you add up the other domains Earthlink owns, it's even higher in the list...
m ains/index.jsp
http://webmail.atl.earthlink.net/wam/supported_do
-- Terry
R&D Costs for driver development can't be recouped
When BusLogic came out with their AHA1540/AQHA1542 compatible SCSI controllers, they did several things:
(1) They leveraged Adaptec's R&D effort on driver development so that they didn't have to spend their own money developing drivers.
(2) They avoid the effort of convincing Microsoft to ship with the drivers as part of Windows; never underestimate the barrier to entry a separate driver disk represents: for NT 3.51, you had to install the driver disk twice during the installation process, and a third time post-install to use a third party disk controller, and it was not well documented where or when NT 3.51 would reference the disk, not find it, and simply crash (you "just had to know").
(3) By making the card's interface compatible with an existing card, they avoided all the R&D necessary to get from a concept to a working interface.
So basically, BusLogic got a free ride on Adaptec's dime in a number of areas, and Adaptec was left holding the bag, having to charge a higher amount to recoup their R&D investment, leaving BusLogic to undercut their prices and steal their market.
That's not to say that I totally agree with Adaptec, or that bad designs which can't be safely exposed without risking physical damage to the devices (Diamond Multimedia video cards[*]) or legal repercussions (Oscillator/PLL tuned WiFi cards that don't have hard-wired frequency bands) don't exist, but I can certainly understand the position of companies who don't want to sacrifice hard-earned product lead-times, OS vendor relationships, or actual R&D results on the altar of public domain.
[*] Diamond, in particular, pisses me off, since any halfway decent software engineer could have separated the model and view from the controller, and made their cards both Open Source friendly and non-x86 architecture friendly, and the EE who wrote the firmware didn't.
-- Terry
If Intel is an 800lb gorilla, Microsoft is 1600lbs
Intel's ACPI reference implementation doesn't work with a lot of hardware, despite great efforts being made by both Intel and FreeBSD, all the vendors code their ACPI implementations to the point that they work with the Windows ACPI implementation (not derived from Intel's reference), and no farther.
If Intel had the power in the market that you're claiming for it, then all boards out there would work with the ACPI reference implementation, and FreeBSD and Linux would have far fewer headaches.
-- Terry
CA Bottle deposit laws are broken at reclaimation; sure, there's a "CA redemption value" printed on all the plastic bottles -- but when was the last time you saw a redemption center at your local Safeway/Albertsons/Thrifty/Longs/Red Owl/whatever?
I forsee the same problem for any "deposit" law for computer equipment or tennis shoes or whatever.
Putting a deposit on the thing that you reclaim when something is disposed of properly only works if you provide a location where things can be disposed of properly.
As far as I can tell, nobody ever reclaims these things because it's practically impossible, and concientious people end up paying the non-refundable "deposit", and then paying again to have their recyling hauled away to a recyling plant.
-- Terry
Ugh... default return key bindings suck. I also meant ot say:
"...showed that a single atom on a silicon surface can be controllably charged..."
This seems to me that it would take a heck of a lot of shielding, or a lot of redundancy, to prevent accidental state changes interfering with the operation of a device based on such components.
-- Terry
"computer parts could be biodegradable"
Great... bit-rot is now real, instead of just an artifact of idiots not maintaining the contract promised by both sides of an API.
-- Terry
You mean to say that "it's morally wrong", not "it's ethically wrong".
Ethics have to do with personal principles; morals have to do with societal principles.
Morals: Of or concerned with the judgment of the goodness or badness of human action and character.
Ethics: the principles of conduct governing an individual or a profession.
People get confused about this because they hear terms like "medical ethics" or "legal ethics", which really refer to the morals espoused by a specific subset of society, a profession.
It's pretty much impossible to act against one's own ethics: they rule how you act.
Morals are pretty much enforced by society: individuals act morally either because their personal ethical system is in alignment with the general idea of what constitutes moral behaviour, or they do so out of fear of punishment by the society in which a given act would be (a) perceived to be immoral, and (b) the extent to which that society is able to enforce its morals by punishment of those who do not act in accordance with them.
Now that we have that out of the way, lets look and see if it's really "morally wrong", or if you're just expressing your opinion.
The answer to that question, as to whether or not the larger society, in fact, views the act as immoral, ultimately depends on whether or not your opinion represents a majority.
The issue here is whether or not the existing laws were paid for by special interests, or were enacted to impose the will of the majority on the rest of society. If the latter, then yes, it was immoral. But if the former... then the law will not be upheld in court (jury nullification), or awarded damages will be token rather than punative (e.g. $1), and the act is not in fact immoral.
I think if you were to take a poll here, you would find that the majority of *this* society, Slashdot, do not find the act immoral.
I also think that if you investigate further, neither does the larger society believe the act immoral, particularly given the inflation of ticket prices.
-- Terry
Actually, it's a flaw in the ATA specification: ATA drives can do a disconnected read, but there is no way to do a disconnected write.
Because of this, you can have a tagged command queue for read operations, but there is no way to provide a corresponding one for write operations.
SCSI does not have this limitation, but the bus implementation is much more heavyweight, and therefore more expensive.
The problem is exacerbated, in that ATA does not permit new disconnected read requests to be issues while the non-diconnected write request is outstanding. Therefore, any write acts as a read stall barrier.
In order to compete with SCSI on both write performance, and interleaved read/write operation performance, manufacturers added write caching by default, breaking the historical contract about when a write completes to stable storage vs. the write operation not returning until it did.
Today, there are still a number of disks that *actually* lie, and there are a number of firewire/ATA bridge chipsets that do not propagate the FW sync into an ATA sync, even if you didn't end up with a disk that lied.
So you can be screwed if:
1) The disk lies about honoring the cache flush request (there was one series of Quantum ATA disks that did this, for which Quantum promptly provided a firmware update. I really like Quantum for this, and you can find the discussion on the FreeBSD-hackers mailing list archives).
2) The controller or bridge chipset responds to the flush request, but does not propagate it to the actual devices (there is one popular bridge chip that does this; since it was not recalled by the manufacturer, and there is no firmware update fix possible, in the interests of not being sued, I'm going to avoid naming names here.
3) The OS may not issue the command for user perceived peroformance reasons relative to the competition (this is why, before the cache flush command existed in the ATA specification, FreeBSD turned back on the write cache by default, even though everyone knew that data integrity guarantees *would* go out the window).
Unfortunately, I can no longer just say "ATA sucks; use SCSI", because a number of SCSI disk manufacturers have started doing the same pig tricks with their SCSI disks (again, not naming names), and ignore the SCSI cache flush command, or ignore the mode page setting for synchronous I/O completion with tagged write commands (writing is slow, especially if you have to read an entire track to write a block).
Hopefully, this Slashdot article will cause the mainstream press to put enough light on this issue to shame the drive manufacturers into at least labelling actually compliant drives.
-- Terry
Rather than finding and plugging holes in IIS, we could achieve the desired ends of "safer sites across the board" by having them install something other than IIS.
In other words, using "secure in the first place" software, instead of trying to make "insecure in the first place" software into "secure in the second place" software.
Any "secure in the second place" software still suffers from the top security problem out there: people who don't update their insecure software when patches become available.
Without patching the fact that people don't patch things, you haven't solved anything. The only way to solve *that* problem is to have forced upgrades *or* to have software that doesn't require upgrading for it to be secure.
Just a thought...
-- Terry
You aren't the target market.
People complaining about server installs and power user installs shouldn't use this: they are not the target market, and they should quit complaining and simply not use it: no loss.
Complaining about the desktop choice is another self-defeating proposition: he had to pick *something*, and it had to be one thing to start with, not "pick one of 1000". It also has the benefit of giving a platform target ABI to developers who want to do desktop applications: one of the biggest reasons UNIX systems don't end up with a lot of applications is lack of a uniform target ABI. Even if the API was the same across multiple look-and-feel values, it's not enough to attract developers: requiring a recompilation means doubling their support and testing burdens, as well as their SKU count (if they don't ship all versions on the same CD/DVD).
One of the best things MacOS X did, from this perspective, is *not* open up the GUI code, so that people have a hard time making a zillion incompatible versions and shipping them around, fragmenting the market. I hope he does not cave in to pressure to "pull a RedHat" with a "KDE or Gnome" option.
For the average user, it's a step in the right direction, and one that all of the BSD's, save MacOS X, have been too snobby to take on their own (or too caught up in the myth of the server being the only market space that's a valid target for a BSD based OS).
There are a couple of things that could be changed to make it better, but it's miles above the fear-inspiring raw text prompt and ASCII graphics of the normal FreeBSD installer.
Instead of a hierarchical relationship between things you have to fill out, as in sysinstall, where it's an exercise for the student to traverse the installation/configuration tree, it's a simple linear progression.
Instead of dropping you to a raw login prompt, it drops you to a KDE login.
All in all, it removes much of the "fear barrier" that keeps people from even considering installing a BSD operating system on their machine in the first place.
I dislike the use of the GPL, but given that it's written against a GPL'ed toolkit, it's excusable in the face of what it provides.
Here's what else I think it needs to really polish it off:
o Graphical partition editor
It currently assumes you have a free partition lying around, and it doesn't really permit editing it. I know this is a very hard nut to crack, and that Partition Magic has an entire product dedicated to the task (AFAIK, it's the only product that can safely resize NTFS partitions); I'm not sure how doable this is, but it's near the top of the list.
NB: The only reasonably way I have ever come up with to deal with this, short of contracting the work out the the P.M. people, is a Window NT install program that allocated a chunk of disk space *inside* the NTFS, and then a booter program that is an icon on the NT desktop, and let FreeBSD use the existing allocated NTFS file as a fielsystem, after hacking the block driver to make it appear virtually contiguous. I expect that this will be the last thing on my list implemented, if ever.
o Creation of an "admin" account, rather than root
This would just be the initial user's account, with rights to "sudo"; they could name it anything they wanted to name it. The root account would be disabled by default; you could always enable it via "sudo passwd" later, if you wanted to be able to login as root instead of the user.
o Automatic walk-through for the configuration
If you have an initial account other than the root account, you can walk the user immediately through the account-specific configuration. This would be a smoother transition, rather than stopping, requiring a login, and then continuing.
o Automatic login as the admin user
I realize that this may seem much less anal than a typical UNIX appraoch to things, but it's possible to do this relatively safely, simpy by enabling a screen saver
Thanks for the article reference!
It's close to a "Mini-LSB"; it's unfortunate that it doesn't address the ability to turn off all interfaces not in the standard to trigger compile time errors in non-binary-compatible code. 8-(.
I still think there would be a great deal of resistance to this sort of thing for the reasons cited in my initial post; it would probably take an "artistic license"-style license change to enforce compliance with something like this across vendors.
I don't think that's something we are likely to see happen, given the huge backlash against things like SCSL.
-- Terry
I'm really disappointed with this discussion.
There are a couple of posts that get part of the answer to the question being asked and none of them has been moderated to higher than a 3 (and that one was somewhat off topic).
A few years back, I tried to do something similar to what a part of what LSB attempts to do, and it was like pulling teeth to get anyone to even talk about it. The initive was called FABIO, for "Free Application Binary Interface Objective". The intent was to get all the x86 Linux and BSD distributions to sync up with a single ABI, hopefully derived from a commercial ABI - the front-runner at the time, by far, was Solaris.
Nobody would do it, and it's for the same reasons that FABIO was stillborn, and the LSB is significantly more far-reaching than FABIO ever was:
1) Loss of editorial control
This is a big one for some projects. What if the LSB suddenly includes a library with a license that Debian can't live with, for example? What if I'm building an enterprise version of Linux, and I don't *want* to include graphics drivers that are part of the LSB 3.x specification? This is much less about what to put where as it is about what to include or not include in a distribution, and the acceptable per-distribution licensing policies and practices. The LSB throws in the kitchen sink.
2) Commoditization
If everyone conforms to a standard, what differentiates one product from another? This was touched on in that other posting. So far, no one has used the phrase "UNIX Wars", so I will. The UNIX Wars were about product differentiation. The other posting suggested that this was a result of market forces toward stratification, where different products rise up to meet different sets of needs. This is incorrect. FABIO only intended to standardize ABI - far less than the ambitious LSB. Further, it wanted to pick an existing commercial UNIX to standardize against, and finally, it wanted to define two levels of compliance. In the lowest level, you would be guaranteed that the standardized APIs were present. In the highest leve, you were able to turn off all APIs which were not standard: a guarantee that you could write code without unwittingly using a vendor extension, making the resulting binary non-portable. A mass exodus of developers to level 1 compliant platforms (to obtain the largest possible market) was expected... *if* FABIO made it. Neither the Linux nor the BSD camps bought into the idea: it would have rendered them commodities, differentiated only by philosophy and license. This is the same thing that drove the UNIX Wars: "I can't/won't compete against Microsoft, so I'll drive this other UNIX vendor out of business and take his market instead".
3) It's too big to be meaningful in any real sense
The LSB is too big to implement everything, and if you don't implement everything, you aren't LSB compliant. Face it, it's a superset of POSIX, and there's not one Linux yet that can claim full POSIX conformance for their system, let alone add in the other parts of the specification to get to LSB conformance. It's too damn big, and you can't turn off those things that are optional (you can barely do this with POSIX, using unistd.h, and if you do that with too many things, your system is useless anyway:. There's no agreed upon mandatory subset that lets you turn off the non-mandatory parts, and not get them at all, and know that all other mandatory compliance is there. POSIX has this problem in spades; the unistd.h mechanism is really poor at letting you pick interfaces to *NOT* be there: you can't. You also can't know, without a lot of research, what things are mandatory for conformance with standards built on top of POSIX - this is left as an exercise for the developer, who can say "if this interface is there, use it", but can't go anywhere and ask "what interfaces can I safely use, always, as long as a platform is conformant with standard XXX?". The LSB does a worse job: it includes POSIX, and then adds things on top of
The article says:
I guess compromised servers are just as reliable as uncompromised ones?
-- Terry
Full Disclosure: I'm a Senior Associate with the Institute for Molecular Manufacturing http://imm.org/.
n es.html
I have to say that this article seriously misses the mark.
Recombinant DNA research self-regulation has been in place for 30 years now, and it has worked very well to prevent "Andromeda Strain" style accidents. The most recent full overhaul was in 1994:
http://www4.od.nih.gov/oba/rac/guidelines/guideli
There are people who are holding debates about similar regulation for molecular nanotechnology already: The National Nanotechnology Initiative http://www.nano.gov/, The Foresight Institute http://foresight.org/, The International Council on Nanotechnology http://icon.rice.edu/, and many others, including the IMM. The intent of these organizations is to establish guidelines for developement of nanotechnology, and to explore applications.
Here is the first set of guidelines which have been established:
http://imm.org/guidelines/current.html
I fully expect that this will be updated, as the technologies involved become more capable.
A good analysis of the actual societal implications is available from NNI here:
http://www.nano.gov/html/facts/society.html
Don't blow things out of proportion until they are actually implemented; the amount of regulation of any technology has historically always been as much or even much more than was necessary at the time.
-- Terry
That's not funny, it's insightful.
-- Terry
It's changed - See IRS form 4562 instructions.
3 d0e441
As a special case, you can depreciate PC equipment and software over 3 years if it was purchased ina certain date range, or if it's purely a business asset:
http://www.irs.gov/instructions/i4562/ch02.html%2
But consult your tax professional for rules changes.
See also:
http://www.irs.gov/instructions/i4562/ch02.html
which describes all the depreciation rules used in filling out form 4562 (the form you use to claim depereciation of capital assets).
-- Terry
I meant Gould. I am absolutely terrible with names.
When I mentioned the references to Scopes, of course it was with regard to the mechanics as they were understood directly from Darwin's writings, which meant his understanding of them.
Pushing a non-scientific position is always all about intentionally picking an already discredited theory as a whipping boy, and then citing the evidence that was used to discredit it.
-- Terry