The recession just gives them more impetus to go after some big names.
Then you misse the point of modern Euro-politics completely.
Unlike American politician, they do not do it for the money. They do it for a bump in career. Having Intel conviction on a resume would help the involved politicians in home elections.
EC is overall too corrupt. It is hard to low level politicians to gain anything there, as most of the profits from corruption are already distributed among high level politicians. That's why career for most of them is most important venue. After having a good career in EU, they can return to home country's politics where they would be much larger figures, opening up more corruption prospects.
That's silly. For Intel, CPUs are probably 75% of their revenue. For Siemens, energy distribution is probably like 2-3% of their revenue.
There was more interesting case against 3 major EU-based elevator companies who essentially divided market (refusing customers belonging to competitors' turf) and fixed prices. Since their were engaged in the activities for more than a decade, fine was IIRC 3 times of a year profit. And unfortunately for the companies, the year before the conviction was pretty good financially for all of them.
... the calling program must repeatedly ask for data to be delivered.
I presume that the date on the article is off by 10 years or something. I make the judgment based on the facts that the author calls SCTP "recently developed" and apparently never heard of/dev/epoll or kqueues (or e.g. libevent allowing to use them in portable manner).
Of course, if someone can actually produce some real-world benchmarks that validate the "let's ditch Sockets" claim...
There are really few real world example where you can do something better than sockets.
BSD sockets are quite versatile API. I have programmed them on both side - implementing my own protocol/address family and actually using them in program - and hardly see how one can do it better, maintaining level of guarantees provided by the API. And the level of guarantees what makes it possible to develop applications behaving reliably/predictably under ever varying conditions - and not loose your sanity in the process.
Also what many novice forget that sockets support a number of assertions application can make on sync/async error handling. IOW, one can easily improve performance of BSD socket by simply removing error handling. But something tells me that no-one's gonna do it.
Google News is your friend. And they have more headlines than/. would ever have.
The whole point of/. are user comments. On Ask.Slashdot you might find really really great advices and hints. There is nothing else here what isn't done somewhere else better.
I also value/. commenters as quite well balanced community: you have idiots and trolls, share of those who try to grasp the reality and few of those who really get it. Just like in real life. And like in real life, story to story, commenters show themselves from different prospectives: troll in one discussion might also be an expert in another discussion.
On side note (or on-topic) I wonder how much ad revenue/. needs to be profitable. Probably I need to whitelist/. to see it in all the beauty.
Although I like this proposal, I don't understand why it wouldn't be simpler to just have someone do the sorting for those "ad-server lists". What I want is a block-list that blocks the annoying ads (e.g. flash ads that cover the page) but doesn't block un-annoying ads (e.g. demure text-ads). A whole spectrum of lists, depending on people's tastes, could be constructed. Do these kind of "nice blocking" lists already exist?
As somebody who used till the last moment original AdBlock (not ABP, no subscription, only manual black/white-listing) I can tell you that it is very very hard to differentiate between ads.
Most of the time you need to block a javascript. But often it would have very generic name, making it impossible to tell difference between plain text or image or flash ad, e.g. ad.com/ad_script.cgi?blah-blah-blah.
Essentially, all advertisers provide multitude of marketing strategies and tactics - it is impossible to differentiate between them. Thus the ABP subscriptions block all domains of the advertiser, blocking indiscriminately all ads.
The problem is that after you install ABP, you stop seeing ads. So you even forget that most of the Internet relies on the ads for support.
I honestly couldn't recognize Engadget.com first time (and actually last time) I have visited it in IE: ads are all over the page.
I'm a big girl, I can make these decisions for myself without being nagged by the very piece of software I installed to help enforce my decision in the first place.
ABP would allow to disable the yellow bar and see Internet as before without ads. No nags - only one option.
I still think that idea is a good compromise. If I visit site often, I might want to support it. The only way for me to support it is to allow ads from the site. The problem is that I might not even know that there are ads on the site.
As FireFox (and AdBlock) gain in popularity, some compromise is needed. I in fact seen at least on site in past which demanded me to use IE because FireFox due to AdBlock wasn't supported.
Ironically, this is not funny and quite true for some free hosting providers. My friend was hosting some of his work online on such site. It was free, but every page has to include special code provider used to put ads on his pages.
ABP would only show the yellow bar for sites which you visit often (as judged by your browser history). And you can also turn it off explicitly and keep all stuff blocked as before.
I'm not sure that the proposal would impact anything, but seeing start of the discussion I'm hopeful that some long term solution (e.g. everybody migrates to unobtrusive text-based Google Ads) would be found.
I have seen a number of community sites going offline because though they have hosted ads, most used Opera or FireFox with ad block/etc. Despite high traffic, revenue from ads was miserable and not really sufficient to even support operations.
Trademarks are sort of like authorship. You can transfer copyright to your work to somebody else - but you can't transfer authorship. That's doesn't prevent you from using the work, it only prevents you from imposing on somebody else.
Probably they are better now, but in past they had pretty f***ed up registration process. Now they also feature mostly private torrents and their tracker is more than often down. Needless to mention that they host mostly complete shows - meaning really few of new stuff.
Still, baka + nyaa + anirena are good to track releases of well established funsubbers. You can't beat TokyoTosho if you want to discover more different anime done by some lesser known (or unknown) groups/people.
Not many. I worked mostly with PowerPC/32 based ones and a bit with some (very) old ARM, x86 (Geode) and M68K.
CPUs themselves are fine. But architectures using them are more than often odd. While programming Linux drivers, I personally never had to deal with the peculiarities, as I was using commercially supported embedded distro (BlueCat, MontaVista) where most of the things were already taken care of. Diffing MontaVista kernel versus vanilla kernel was turning up many interesting things they had to do for some proprietary embedded architectures. Nothing not doable, yet it was quite eye-opening what tricks H/W manufacturers has to use to keep systems profitable.
Later on, I also worked for company which was producing niche proprietary embedded system based on PowerPC and M68K CPUs. It was also quite interesting hearing from H/W folks motivation behind throwing out some parts to save say $2.50, when in the end whole system cost something like $2000. Whatever was crippled in hardware (recurring cost) is quite easy to workaround in software (one-time cost).
At the time of strlcpy()/strlcat() inception I read their OpenBSD man pages and it took me a while to understand what the operations are really improving compared to memcpy()/snprintf(). Yes, they are safer than traditional str*cpy()/str*cat(), yet largely redundant, as no self respecting programmer have ever used them for anything else but helloworld.c.
If portability isn't issue (and if you asking for strlcpy()/strlcat() it is apparently not), then for most simple programs you are better off using GNU extension asprintf(). It is also supported by BSD and is magnitudes safer than cascades of str*cat().
Embedded architectures are never well designed. Their purpose is not to win "best design" award - but to be cheap and efficient.
Embedded systems are extremely high volume market. Sparing few transistors here there often saves $$$$$ when you get into shipment volumes with 4-6 zeros at the end. Software development is often one time effort, that's why such oddities (as Ulrich have complained about) with easy workarounds are quite common. Main savings are coming from actual H/W costs.
Frankly, I'd say Ulrich is fitting person for a project like glibc.
I do not think his a bad guy, it's just a job of glibc maintainer (which is a central piece of "Linux OS", second most important after kernel) would make out of anybody an a**hole.
I'd say his job is 99.9% of times saying "NO" to all the silly proposals flying all the time on glibc mail lists.
But it's just in this case he was wrong. Shit happens.
Embedded folks generally more flexible and closer to the ground, compared to many high profile Linux celebrities who generally are kept on payroll by server companies. And Linux on servers this is 95+% x64 - other architectures and application fields simply do not interest them. Or in other words: they are not paid for doing it.
IBM POWER's main power is that they can do custom designs. It's part of their business. IBM is quite different from the rest.
Intel is making only few designs per year and expect them to sell in volumes to turn profit. Same goes to Sun's SPARC: they have to turn good volumes to be profitable. And as some knowledgeable commented above they do.
As long as Oracle doesn't screw up management, there will always be a place for tightly integrated vertical business model like SPARC's. (Otherwise, Lintel/*BSD/x64 would have already taken over the markets.) IBM btw uses AIX/POWER in the way: they sell vertically integrated stack of H/W, OS and business software (+ their SAN). Oracle is only need to follow their footsteps and sell vertical stack of H/W, OS, SAN and DB/etc software. And it would sell. There is a market for such integrated solutions.
PPC largely remains inferior (performance-wise) to Intel offering. (*)
But.
POWER != PowerPC. POWER can PowerPC, but PowerPC can't POWER.
Frankly, I'm too at loss when it comes to defining what is POWER and what is PowerPC. I had impression that with actual generation - POWER6 - IBM simply unified/merged PowerPC/64 to its existing server architecture. (Or unified their marketing.) So now there is only POWER or Power Architecture.
Though they still sell heck of 4xx CPUs which are (1) PowerPC/32, (2) dirt cheap (3) (relatively) fast (4) power efficient and (5) dirt cheap. Also everybody buy them because they are dirt cheap.
(*) IBM/Apple divorce had little to do with PowerPC underperforming. IBM pushed hard Apple to invest more into PowerPC R&D. Apple refused. There were problems with power consumption of newer workstation chips too. And IBM failed several dead-lines, making Apple's PR look bad. As performance goes, some math applications are still faster on PowerPC than they are on Intel. It's just generally, Intel market has much more cheap solutions, compared to proprietary PowerPC architecture, designed especially for Apple. E.g. video encoding can be much faster on PowerPC, yet on Intel it is faster because it is simply more and better optimized. It's not black and white. Intel wins hands down mostly because there are so many people using the CPUs.
The CoolThreads stuff is neat, but never really took off at the volume Sun was hoping.
It's way too Java biased.
My company did evaluation (C/C++ stack of applications) with only one result: disabling the CPU multithreading capabilities improves performance. Otherwise, sustained performance penalty makes the whole solution not worth its money.
But it would be interesting to see how they do Java applications. In our stack, Java has bits of business logic, but mostly (one of the) front-end(s) for customers to hook up their own applications - it's not performance critical thus was not evaluated.
As for POWER...there will always be people who need the biggest, fastest, baddest processor. A lot less people need them than they used to - x86 commodity keeps getting faster. But there will always be the top X% of the market that needs speed. That's why IBM sells POWER. And hey, while we're catering to them, we can also use it in our run-of-the-mill servers (AIX, AS/400, Mainframe, etc.)
I think POWER has a lot more staying power than SPARC.
I always had the opinion that IBM keeps POWER floating simply because it's pretty much always delivers profits. The POWER among architectures is like Linux among OSs: it scales from embedded systems to clusters to mainframes. IBM is pragmatical company and POWER apparently sells well: there seems to be undying demand for custom chips for all possible applications. Provided simplicity of POWER (some folks do implement PPC32 of FPGA) IBM can very quickly adjust it to requirements of a customer. If one market is slowing, other markets do support future development.
In contrast, SPARC to be profitable has to have a wider market: it's not that flexible accommodating various application fields. They are present in essentially one (huge) market: servers. Yes, it's huge - but highly competitive market. In past, the sole reason for people to buy SPARC was Solaris: good, stable - slow - yet best server OS. I'm not sure how that would play out after Oracle's take over. Seeing how now Oracle runs on Linux/x64, I have strong feeling that SPARC might be the first business unit sacrificed. Solaris/x64 (which Sun already produces) might be way too tempting for Oracle as a way forward.
DISCLAMER: I work for one of the 3 companies involved here. Not the one you might think.
There is only one company not mentioned in the thread which has something at stake here: HP.
Reading the mood in the industry, I'd say HP-UX would die sooner than AIX or (Open)Solaris. AIX simply has no chances of dying - IBM develops it completely in-house and uses it as private platform for all possible top-down solution. Solaris is way too vital asset, in several industries considered to be a standard OS: it would be dying (if ever) very very long time. HP-UX, though absorbed Tru64, due to lacking features, extremely slow development and generally poor management, lost it's traditional HPC customer base to Linux. SuperDomes are interesting, but few can afford them. Neither HP has strong software development. They are way too often H/W supplier and that's it - way too easy to replace.
Accepted. I personally know only horrors of WinNT4.0 - there was no fork() there. Essentially, if program used anything beside stdio, one should have expected problems.
Yet, unless I see some real programs using the said POSIX API, I would stay very very skeptical. The SFU was interesting in a way, but seems like went nowhere.
It's like the topic: yes, M$Office2k7 supports ODF, but it's still useless.
But to the point. If Windows supports fork(), please show to me its MSDN help page. All crap Windows supports - or supported in past - is on MSDN. But not fork(). I searched - found none.
I wonder why then CygWin people invested several years into implementing it? Why Strawberry Perl does it's own way? Why whole internet filled with threads "how to fork() in Windows"?
Or probably it's only you who needs to RTFM before posting? Quote:
One of the largest areas of difference is in the process model. UNIX has fork; Win32 does not.
[...]
This page is specific to
Microsoft Visual Studio 2008/.NET Framework 3.5
Slashdot Mirror
The recession just gives them more impetus to go after some big names.
Then you misse the point of modern Euro-politics completely.
Unlike American politician, they do not do it for the money. They do it for a bump in career. Having Intel conviction on a resume would help the involved politicians in home elections.
EC is overall too corrupt. It is hard to low level politicians to gain anything there, as most of the profits from corruption are already distributed among high level politicians. That's why career for most of them is most important venue. After having a good career in EU, they can return to home country's politics where they would be much larger figures, opening up more corruption prospects.
Siemens Market Cap: Ã 45.85 billion Intel Market Cap: Ã 62.26 billion
That's silly. For Intel, CPUs are probably 75% of their revenue. For Siemens, energy distribution is probably like 2-3% of their revenue.
There was more interesting case against 3 major EU-based elevator companies who essentially divided market (refusing customers belonging to competitors' turf) and fixed prices. Since their were engaged in the activities for more than a decade, fine was IIRC 3 times of a year profit. And unfortunately for the companies, the year before the conviction was pretty good financially for all of them.
Ignore the RTFA. Quote:
I presume that the date on the article is off by 10 years or something. I make the judgment based on the facts that the author calls SCTP "recently developed" and apparently never heard of /dev/epoll or kqueues (or e.g. libevent allowing to use them in portable manner).
Of course, if someone can actually produce some real-world benchmarks that validate the "let's ditch Sockets" claim...
There are really few real world example where you can do something better than sockets.
BSD sockets are quite versatile API. I have programmed them on both side - implementing my own protocol/address family and actually using them in program - and hardly see how one can do it better, maintaining level of guarantees provided by the API. And the level of guarantees what makes it possible to develop applications behaving reliably/predictably under ever varying conditions - and not loose your sanity in the process.
Also what many novice forget that sockets support a number of assertions application can make on sync/async error handling. IOW, one can easily improve performance of BSD socket by simply removing error handling. But something tells me that no-one's gonna do it.
That explains why - fortunately - it wasn't widely adopted.
Google News is your friend. And they have more headlines than /. would ever have.
The whole point of /. are user comments. On Ask.Slashdot you might find really really great advices and hints. There is nothing else here what isn't done somewhere else better.
I also value /. commenters as quite well balanced community: you have idiots and trolls, share of those who try to grasp the reality and few of those who really get it. Just like in real life. And like in real life, story to story, commenters show themselves from different prospectives: troll in one discussion might also be an expert in another discussion.
On side note (or on-topic) I wonder how much ad revenue /. needs to be profitable. Probably I need to whitelist /. to see it in all the beauty.
Although I like this proposal, I don't understand why it wouldn't be simpler to just have someone do the sorting for those "ad-server lists". What I want is a block-list that blocks the annoying ads (e.g. flash ads that cover the page) but doesn't block un-annoying ads (e.g. demure text-ads). A whole spectrum of lists, depending on people's tastes, could be constructed. Do these kind of "nice blocking" lists already exist?
As somebody who used till the last moment original AdBlock (not ABP, no subscription, only manual black/white-listing) I can tell you that it is very very hard to differentiate between ads.
Most of the time you need to block a javascript. But often it would have very generic name, making it impossible to tell difference between plain text or image or flash ad, e.g. ad.com/ad_script.cgi?blah-blah-blah.
Essentially, all advertisers provide multitude of marketing strategies and tactics - it is impossible to differentiate between them. Thus the ABP subscriptions block all domains of the advertiser, blocking indiscriminately all ads.
The problem is that after you install ABP, you stop seeing ads. So you even forget that most of the Internet relies on the ads for support.
I honestly couldn't recognize Engadget.com first time (and actually last time) I have visited it in IE: ads are all over the page.
I'm a big girl, I can make these decisions for myself without being nagged by the very piece of software I installed to help enforce my decision in the first place.
ABP would allow to disable the yellow bar and see Internet as before without ads. No nags - only one option.
I still think that idea is a good compromise. If I visit site often, I might want to support it. The only way for me to support it is to allow ads from the site. The problem is that I might not even know that there are ads on the site.
As FireFox (and AdBlock) gain in popularity, some compromise is needed. I in fact seen at least on site in past which demanded me to use IE because FireFox due to AdBlock wasn't supported.
Ironically, this is not funny and quite true for some free hosting providers. My friend was hosting some of his work online on such site. It was free, but every page has to include special code provider used to put ads on his pages.
Read the darn blog post again.
ABP would only show the yellow bar for sites which you visit often (as judged by your browser history). And you can also turn it off explicitly and keep all stuff blocked as before.
I'm not sure that the proposal would impact anything, but seeing start of the discussion I'm hopeful that some long term solution (e.g. everybody migrates to unobtrusive text-based Google Ads) would be found.
I have seen a number of community sites going offline because though they have hosted ads, most used Opera or FireFox with ad block/etc. Despite high traffic, revenue from ads was miserable and not really sufficient to even support operations.
In other words it is all about identity.
Trademarks are sort of like authorship. You can transfer copyright to your work to somebody else - but you can't transfer authorship. That's doesn't prevent you from using the work, it only prevents you from imposing on somebody else.
Seems pretty logical to me.
I use nyaatorrents
Then you might be also interested in Anirena. Lots of groups track their releases here too.
Probably they are better now, but in past they had pretty f***ed up registration process. Now they also feature mostly private torrents and their tracker is more than often down. Needless to mention that they host mostly complete shows - meaning really few of new stuff.
If you want a anime release search try baka-updates.com
That's a good hint! And they also have RSS.
Still, baka + nyaa + anirena are good to track releases of well established funsubbers. You can't beat TokyoTosho if you want to discover more different anime done by some lesser known (or unknown) groups/people.
You have to remember that Mininova was always something secondary/tertiary - before first SuperNova and then TorrentSpy both went under.
It had became "largest" solely because RIAA/MPAA have eliminated already everybody larger than MN.
TokyoTosho probably remains now sole source of anime torrents.
Not many. I worked mostly with PowerPC/32 based ones and a bit with some (very) old ARM, x86 (Geode) and M68K.
CPUs themselves are fine. But architectures using them are more than often odd. While programming Linux drivers, I personally never had to deal with the peculiarities, as I was using commercially supported embedded distro (BlueCat, MontaVista) where most of the things were already taken care of. Diffing MontaVista kernel versus vanilla kernel was turning up many interesting things they had to do for some proprietary embedded architectures. Nothing not doable, yet it was quite eye-opening what tricks H/W manufacturers has to use to keep systems profitable.
Later on, I also worked for company which was producing niche proprietary embedded system based on PowerPC and M68K CPUs. It was also quite interesting hearing from H/W folks motivation behind throwing out some parts to save say $2.50, when in the end whole system cost something like $2000. Whatever was crippled in hardware (recurring cost) is quite easy to workaround in software (one-time cost).
At the time of strlcpy()/strlcat() inception I read their OpenBSD man pages and it took me a while to understand what the operations are really improving compared to memcpy()/snprintf(). Yes, they are safer than traditional str*cpy()/str*cat(), yet largely redundant, as no self respecting programmer have ever used them for anything else but helloworld.c.
If portability isn't issue (and if you asking for strlcpy()/strlcat() it is apparently not), then for most simple programs you are better off using GNU extension asprintf(). It is also supported by BSD and is magnitudes safer than cascades of str*cat().
Embedded architectures are never well designed. Their purpose is not to win "best design" award - but to be cheap and efficient.
Embedded systems are extremely high volume market. Sparing few transistors here there often saves $$$$$ when you get into shipment volumes with 4-6 zeros at the end. Software development is often one time effort, that's why such oddities (as Ulrich have complained about) with easy workarounds are quite common. Main savings are coming from actual H/W costs.
Drepper has had this coming for many, MANY years.
Frankly, I'd say Ulrich is fitting person for a project like glibc.
I do not think his a bad guy, it's just a job of glibc maintainer (which is a central piece of "Linux OS", second most important after kernel) would make out of anybody an a**hole.
I'd say his job is 99.9% of times saying "NO" to all the silly proposals flying all the time on glibc mail lists.
But it's just in this case he was wrong. Shit happens.
Embedded folks generally more flexible and closer to the ground, compared to many high profile Linux celebrities who generally are kept on payroll by server companies. And Linux on servers this is 95+% x64 - other architectures and application fields simply do not interest them. Or in other words: they are not paid for doing it.
Forking is right way to go here.
IBM POWER's main power is that they can do custom designs. It's part of their business. IBM is quite different from the rest.
Intel is making only few designs per year and expect them to sell in volumes to turn profit. Same goes to Sun's SPARC: they have to turn good volumes to be profitable. And as some knowledgeable commented above they do.
As long as Oracle doesn't screw up management, there will always be a place for tightly integrated vertical business model like SPARC's. (Otherwise, Lintel/*BSD/x64 would have already taken over the markets.) IBM btw uses AIX/POWER in the way: they sell vertically integrated stack of H/W, OS and business software (+ their SAN). Oracle is only need to follow their footsteps and sell vertical stack of H/W, OS, SAN and DB/etc software. And it would sell. There is a market for such integrated solutions.
PPC largely remains inferior (performance-wise) to Intel offering. (*)
But.
POWER != PowerPC. POWER can PowerPC, but PowerPC can't POWER.
Frankly, I'm too at loss when it comes to defining what is POWER and what is PowerPC. I had impression that with actual generation - POWER6 - IBM simply unified/merged PowerPC/64 to its existing server architecture. (Or unified their marketing.) So now there is only POWER or Power Architecture.
Though they still sell heck of 4xx CPUs which are (1) PowerPC/32, (2) dirt cheap (3) (relatively) fast (4) power efficient and (5) dirt cheap. Also everybody buy them because they are dirt cheap.
(*) IBM/Apple divorce had little to do with PowerPC underperforming. IBM pushed hard Apple to invest more into PowerPC R&D. Apple refused. There were problems with power consumption of newer workstation chips too. And IBM failed several dead-lines, making Apple's PR look bad. As performance goes, some math applications are still faster on PowerPC than they are on Intel. It's just generally, Intel market has much more cheap solutions, compared to proprietary PowerPC architecture, designed especially for Apple. E.g. video encoding can be much faster on PowerPC, yet on Intel it is faster because it is simply more and better optimized. It's not black and white. Intel wins hands down mostly because there are so many people using the CPUs.
The CoolThreads stuff is neat, but never really took off at the volume Sun was hoping.
It's way too Java biased.
My company did evaluation (C/C++ stack of applications) with only one result: disabling the CPU multithreading capabilities improves performance. Otherwise, sustained performance penalty makes the whole solution not worth its money.
But it would be interesting to see how they do Java applications. In our stack, Java has bits of business logic, but mostly (one of the) front-end(s) for customers to hook up their own applications - it's not performance critical thus was not evaluated.
As for POWER...there will always be people who need the biggest, fastest, baddest processor. A lot less people need them than they used to - x86 commodity keeps getting faster. But there will always be the top X% of the market that needs speed. That's why IBM sells POWER. And hey, while we're catering to them, we can also use it in our run-of-the-mill servers (AIX, AS/400, Mainframe, etc.)
I think POWER has a lot more staying power than SPARC.
I always had the opinion that IBM keeps POWER floating simply because it's pretty much always delivers profits. The POWER among architectures is like Linux among OSs: it scales from embedded systems to clusters to mainframes. IBM is pragmatical company and POWER apparently sells well: there seems to be undying demand for custom chips for all possible applications. Provided simplicity of POWER (some folks do implement PPC32 of FPGA) IBM can very quickly adjust it to requirements of a customer. If one market is slowing, other markets do support future development.
In contrast, SPARC to be profitable has to have a wider market: it's not that flexible accommodating various application fields. They are present in essentially one (huge) market: servers. Yes, it's huge - but highly competitive market. In past, the sole reason for people to buy SPARC was Solaris: good, stable - slow - yet best server OS. I'm not sure how that would play out after Oracle's take over. Seeing how now Oracle runs on Linux/x64, I have strong feeling that SPARC might be the first business unit sacrificed. Solaris/x64 (which Sun already produces) might be way too tempting for Oracle as a way forward.
DISCLAMER: I work for one of the 3 companies involved here. Not the one you might think.
There is only one company not mentioned in the thread which has something at stake here: HP.
Reading the mood in the industry, I'd say HP-UX would die sooner than AIX or (Open)Solaris. AIX simply has no chances of dying - IBM develops it completely in-house and uses it as private platform for all possible top-down solution. Solaris is way too vital asset, in several industries considered to be a standard OS: it would be dying (if ever) very very long time. HP-UX, though absorbed Tru64, due to lacking features, extremely slow development and generally poor management, lost it's traditional HPC customer base to Linux. SuperDomes are interesting, but few can afford them. Neither HP has strong software development. They are way too often H/W supplier and that's it - way too easy to replace.
Accepted. I personally know only horrors of WinNT4.0 - there was no fork() there. Essentially, if program used anything beside stdio, one should have expected problems.
Yet, unless I see some real programs using the said POSIX API, I would stay very very skeptical. The SFU was interesting in a way, but seems like went nowhere.
It's like the topic: yes, M$Office2k7 supports ODF, but it's still useless.
True.
But to the point. If Windows supports fork(), please show to me its MSDN help page. All crap Windows supports - or supported in past - is on MSDN. But not fork(). I searched - found none.
I wonder why then CygWin people invested several years into implementing it? Why Strawberry Perl does it's own way? Why whole internet filled with threads "how to fork() in Windows"?
Or probably it's only you who needs to RTFM before posting? Quote:
One of the largest areas of difference is in the process model. UNIX has fork; Win32 does not.
[...]
This page is specific to
Microsoft Visual Studio 2008/.NET Framework 3.5