In layman's terms, formally proven software is software written twice, once as a formal specification, and once as code, and then the two are proven to be equivalent. This is a labour-intensive way to write software, and it makes bugs much less likely, but it's not perfect: there can be corresponding errors in both the code and the specification, and there can be errors in the proof too. But nothing is perfect, and this certainly can be a good approach to write code that is as close as possible to bug-free.
I've worked insane work weeks. I was well compensated for it -- at the time, I needed the money more than I needed the personal time. Now I work sane work weeks because I need the personal time more than I need the money. There may be very good reasons to work insane work weeks for a while -- you need a lot of money in a short time, you need to jumpstart your career or make a career shift, you need to do two major things at once (e.g. study and work), you want your startup to succeed before the venture capital dries up, etc. But life is about more than work -- few people retire thinking "gee, I should have spent less time with my family and more time working".
As for the US, consider carefully some of the reasons why people choose to work insane hours for a while: many of these (opportunity to make a lot of money in a little time, startup company must succeed before venture capital runs out) are more common in the US than in other countries because of the amount of money available there for new IT development. Simply put, the more good reasons there are for people to work crazy hours, the more people will do so, and it's the prevalence of those good reasons that is behind the large number of people in the US working crazy hours.
Let's face it: Apple isn't going to give away their code -- it's not part of their corporate culture. So either they write their own proprietary stuff as they have up until now, or they start with open source and write their own proprietary stuff on top. Quite frankly, it's better for the community that they do the latter: at least there's a better chance at interoperability, and at least the community will know something about the guts of Apple's OS. Yes, it'd be nice if Apple gave back to the open source community everything they do, but it's not going to happen because of what Apple is as a company and how it works.
Bottom line -- it's good that apple is using open source, even if it isn't giving its changes back to the community, because otherwise Apple would have stuck with completely proprietary software.
Phone numbers have far less intrinsic meaning than URLs, and thus are much harder for people to look up and remember. They're a concession to the limitations of 19th-century telephone technology.
The lack of semantic information in phone numbers has very real implications. For example, it's easy to distinguish between http://www.sexshoppe.com and http://www.holyangelschurch.org because of the semantic information in each URL, but if the Sex Shoppe's phone number is 555-1234 and the phone number of Holy Angels Church is 555-1235, there's nothing in the phone number to tell you that the number you are about to dial to book your wedding,
will, because of a single-digit transcription error, result in a rather interesting conversation with somebody whose expertise is likely to be far more useful during the honeymoon than during the ceremony.
Re:Was Linux the competitor?
on
Endgame For SCO
·
· Score: 2
I'm not at all certain that the problem for SCO is that their systems are being replaced by Linux systems (although that's possible, given that Linux offers some real advantages over UnixWare, including price). Rather, the real issue as I see it is this: most new purchases of UNIX for x86 hardware are now Linux rather than SCO: the UNIX-on-x86 market is growing rapidly and almost none of this growth is going to SCO. Thus, even though they're not losing huge chunks of their installed base, SCO's percentage market share is shrinking rapidly. The effects of this are unpleasant for SCO: application vendors increasingly choose to write for Linux rather than UnixWare.
Not all APIs are created equal. Some are published and intended for use by all. Others are experimental or prototypical and thus subject to change -- these are rarely published. Still others may be designated "internal" by Microsoft, published only within Microsoft itself, and used only by its own applications. The last sort are what the court is worried about: it allows Microsoft to build facilities into its operating systems that only its own applications can take advantage of, thus using its operating system monopoly to give its application software packages an unfair advantage over their competitors.
It's unfortunate that this will force Microsoft to disclose experimental or prototypical APIs as well, though. Such APIs change a fair bit, and if people start using them, their applications will tend to break from service pack to service pack, and further, these applications may be exercising OS code paths that may not yet be intended for production use. Windows application software isn't all well-behaved, and Microsoft already has enough difficulties in accommodating badly written application software.
While it's not entirely clear how much of the announcement is a serious attempt to provide email to all Costa Ricans, and how much is merely a public relations stunt, even a partial effort is better than none. Because computer technology can be expensive, internet accessibility is something difficult for poorer people to obtain. But as email and internet accessibility becomes more important in education, business, etc, this lack becomes more and more of a barrier to the poor in their struggle to improve their socioeconomic situation. A negative feedback cycle can result: as email and internet access becomes more and more important, the poor become less and less able to improve their socioeconomic status to pay for the equipment, education and services required to obtain said access. A centralized effort to provide accessibility to all can help overcome this negative feedback cycle and can help provide the means for the poorer members of society to better their situation.
While it is true, in theory, that Microsoft could move from Redmond to BC, it won't free them from the spectre of US antitrust legislation, since presumably they want to continue doing business (i.e. selling product) in the US. Of course, Microsoft could move anyway, as a way of "punishing" the DOJ and the US government. But it would be extremely expensive and disruptive for them to do it -- I doubt they will. Still, it's useful for Microsoft to have this sort of proposal floating around, since it creates fear in the minds and hearts of people in the US, esp. in the northwest, who think it might be serious. This fear may push them into supporting Microsoft in its struggle with the DOJ.
Clustering far predates Beowulf or Linux; at the University of Toronto, we've been doing clustering work for years, and some of it has been successfully commercialized, e.g. LSF. The techniques are fairly straightforward, and there's no real way to keep any particular country from building a compute cluster. Of course, a cluster is not a supercomputer: as Henry Spencer once put it, you can get a lot more work out of a couple of stout oxen than a hundred chickens.
Slashdot Mirror
Some quick "back of the envelope" swine flu risk calculations.
Forget hair. Sand works better!
In layman's terms, formally proven software is software written twice, once as a formal specification, and once as code, and then the two are proven to be equivalent. This is a labour-intensive way to write software, and it makes bugs much less likely, but it's not perfect: there can be corresponding errors in both the code and the specification, and there can be errors in the proof too. But nothing is perfect, and this certainly can be a good approach to write code that is as close as possible to bug-free.
As for the US, consider carefully some of the reasons why people choose to work insane hours for a while: many of these (opportunity to make a lot of money in a little time, startup company must succeed before venture capital runs out) are more common in the US than in other countries because of the amount of money available there for new IT development. Simply put, the more good reasons there are for people to work crazy hours, the more people will do so, and it's the prevalence of those good reasons that is behind the large number of people in the US working crazy hours.
Bottom line -- it's good that apple is using open source, even if it isn't giving its changes back to the community, because otherwise Apple would have stuck with completely proprietary software.
The lack of semantic information in phone numbers has very real implications. For example, it's easy to distinguish between http://www.sexshoppe.com and http://www.holyangelschurch.org because of the semantic information in each URL, but if the Sex Shoppe's phone number is 555-1234 and the phone number of Holy Angels Church is 555-1235, there's nothing in the phone number to tell you that the number you are about to dial to book your wedding, will, because of a single-digit transcription error, result in a rather interesting conversation with somebody whose expertise is likely to be far more useful during the honeymoon than during the ceremony.
I'm not at all certain that the problem for SCO is that their systems are being replaced by Linux systems (although that's possible, given that Linux offers some real advantages over UnixWare, including price). Rather, the real issue as I see it is this: most new purchases of UNIX for x86 hardware are now Linux rather than SCO: the UNIX-on-x86 market is growing rapidly and almost none of this growth is going to SCO. Thus, even though they're not losing huge chunks of their installed base, SCO's percentage market share is shrinking rapidly. The effects of this are unpleasant for SCO: application vendors increasingly choose to write for Linux rather than UnixWare.
It's unfortunate that this will force Microsoft to disclose experimental or prototypical APIs as well, though. Such APIs change a fair bit, and if people start using them, their applications will tend to break from service pack to service pack, and further, these applications may be exercising OS code paths that may not yet be intended for production use. Windows application software isn't all well-behaved, and Microsoft already has enough difficulties in accommodating badly written application software.
While it's not entirely clear how much of the announcement is a serious attempt to provide email to all Costa Ricans, and how much is merely a public relations stunt, even a partial effort is better than none. Because computer technology can be expensive, internet accessibility is something difficult for poorer people to obtain. But as email and internet accessibility becomes more important in education, business, etc, this lack becomes more and more of a barrier to the poor in their struggle to improve their socioeconomic situation. A negative feedback cycle can result: as email and internet access becomes more and more important, the poor become less and less able to improve their socioeconomic status to pay for the equipment, education and services required to obtain said access. A centralized effort to provide accessibility to all can help overcome this negative feedback cycle and can help provide the means for the poorer members of society to better their situation.
While it is true, in theory, that Microsoft could move from Redmond to BC, it won't free them from the spectre of US antitrust legislation, since presumably they want to continue doing business (i.e. selling product) in the US. Of course, Microsoft could move anyway, as a way of "punishing" the DOJ and the US government. But it would be extremely expensive and disruptive for them to do it -- I doubt they will. Still, it's useful for Microsoft to have this sort of proposal floating around, since it creates fear in the minds and hearts of people in the US, esp. in the northwest, who think it might be serious. This fear may push them into supporting Microsoft in its struggle with the DOJ.
Clustering far predates Beowulf or Linux; at the University of Toronto, we've been doing clustering work for years, and some of it has been successfully commercialized, e.g. LSF. The techniques are fairly straightforward, and there's no real way to keep any particular country from building a compute cluster. Of course, a cluster is not a supercomputer: as Henry Spencer once put it, you can get a lot more work out of a couple of stout oxen than a hundred chickens.