[...] it is hard to find any negative articles on PGP, probably because most of them are written by IT pros who are only focused on the security, and not usability.
What you mean they care not or usability"?????
What about the nice view on crematorium out of your safe and secure cell??? with the nice blue smoke of burning bodies of idiots who doubted guards abilities????? That high electrified barbed wire fence looks sooo sexy in the night under lights of nazi guards' lights. And in the concentration camp they also allow you whooping five(!!!) minute walk!!!!!
What could be better that be safe and under watchful eye of trained professionals???
P.S. On serious side though, you might have not found any sensible articles on PGP whole disk thing because nobody uses it. I knew couple of people in past who for that whole purpose were installing Linux. Yet, their setup was much much more saner: standard Linux setup (bunch of normal partitions) + encrypted partition for sensitive documents and/tmp + disabled swap (lots of memory was installed on the notebook specifically for the purpose).
Pretty much natural choice for all who can't (or refuses) to grok Perl, yet want to have a real language at their disposal.
That's flamebait.
Unintentional. I wrote it that way since Perl has been polarizing people: some love it, some hate it.
But frankly, if you look back in the times of PHP inception, Python wasn't there yet. It was still some toy language made by some guy called van Rossum to be used as educational tool. Perl was pretty much de facto language for Web. PHP provided templates for web pages what allowed to put some designers to do work without much understanding by using plain copy-pasting.
Now you already can't choose/change language easily as you could in past. Service libraries and frameworks - as per project requirements - pretty much define what language one would use. You wouldn't want to start every new project from ground zero. (N.B. The topic here is namespaces in PHP. The whole point of namespaces is to facilitate development of components.)
CGI days (only technical requirement is standard input and output) are long gone. You gonna end up with huge performance problems unless you would use something more modern and advanced than trivial piping. PHP, as something running inside web server, also put some nails into CGI coffin.
Now I'm slowly getting why people even bother to use Python for Web. Pretty much natural choice for all who can't (or refuses) to grok Perl, yet want to have a real language at their disposal.
I used PHP around year 2000. It was simple like toy. But it seems that its developers didn't realize that the language did outgrow the sandbox they were living in. Also - the responsibility they carry before all the web developers who invested time into learning PHP.
It seems that the PHP developers had chosen path of M$VB.
You should say "thanks" they haven't chosen something else. e.g Jam (build system; make analog) uses "!" as a "platform neutral" path separator. During evaluations for new build system I joked that I oppose jam since we do not need a "platform neutral" system - we need one for *nix and cygwin. To my surprise many supported me.
I think their decision to use '\' is very very dumb one.
I'm still huge fan of Objective-C in that aspect. Unlike C++, which tried to marry C and objects, ObjC took more pragmatic approach: C constructs remains C constructs and object oriented constructs got new distinctive syntax so that you can never mix up what code you are looking at.
In that aspect, I think PHP folks would regret their decision in future: '\' isn't distinctive enough and they would need to introduce more silly syntax hacks when extending language further.
And yet, here we are, manufacturing the same damn problem for ourselves in Linux with Xorg default file location specifications, which really shouldn't be.
Simple idea came to my mind as I read your response.
That's what I was missing on Windows for quite some time: add a "Find a File" button to open/save file dialogs. (Yes, save file dialog also needs one for the case when one wants to save a new file along with another existing one or simply overwrite old file.) Clicking the button might toggle between picking a file and searching a file.
That solves problem for most "idiot" end-users (e.g. my parents being good example) who are only capable to learn and to work with one application (e.g. OOWriter).
For the children: please, don't do it.
I noticed that some children in fact has no problem using `find ~ -type f` - it is for their parents we need to come up with something.
We need a consistent experience across GNOME, KDE, OpenOffice and Firefox so that content can flow from app to app in a seamless fashion and the user's expectations can be met no matter which app or environment they happen to use.
In Windows we have survived several such attempts. e.g. "Recent File" or "Documents" in Start menu; or the useless location buttons in open/save file dialogs.
Let's just hope I would be still able to open a file at random location. Because the statement makes me feel that eventually I would be able to find all possible files - system thinks I may need to find, but not the files I actually need.
I've personally had the experience of trying to find a file for a customer who had just finished editing a critical report, saved it, and then couldn't locate it to deliver to their client.
Orienting future development on full idiots worked well in past... Or not? Well, GNOME full of it already and another drop of inusability into the mix will not hurt much its rabid fans.
You seem to not read carefully the most important part: "Microsoft's engineers seem to be really committed to making Samba fully interoperable with AD"
M$ engineers are normal folks like you and me. Well, probably not me. The all cr*p breaks loose when M$ management gets involved and start pushing its political agendas.
If cooperation between AD and Samba folks would be successful, rest assured some M$ managers would try to stick themselves into the project to get a free share of credit for the success.
Whose bright idea was it to make the clientspec an unversioned artifact?
ClearCase has the same sickness.
We have periodic breakages since people routinely use wrong config_specs or simply make a typo there.
CC's dynamic views are no solution and even ten people compiling something in parallel overload one server very easily. And the fact that dynamic view doesn't allow you to select what to have in the view (you have always whole repo - like... WHOLE F***ING REPOSITORY) is another plain suckage.
Did you ever tried to code yourself? You look/sound like idiot here.
General rule is quite simple: to thoroughly test code written in 1 day, you need 2 days. If you spent one week developing piece of code, to test it you would need at least another week. That's already two weeks without revision control.
This is sure recipe for disaster and some companies even have rules to checkin everything at the end of the day as to not to loose something to computer failure.
You can backup repositories on server - you can't backup everybody's hard drive.
We are all happy to acknowledge here that you have read "Version control for Dummies" book already and have plethora of theoretical advices for people who manage and do coding of huge codebases in large organizations.
On practical side, though, it seems you never actually tried to organize team out of two programmers. Because even two coders with same coding style following same rules would immediately declare that they want three branches: one main (to merge their work) and two for each other to work independently. In SVN having three branches is P.I.T.A. In git this is trivial. In SVN managers can control what devels do. In git - they can't. Consequently choice of SCM falls onto management and degree of control over developers you want to exercise. Generally, large organizations have too much organizational overhead leading to use of centralized systems like SVN. Git just adds to the management mess.
Practically feasible solution is hybrid to make everybody happy: use SVN on R&D (department) level; let teams maintain their own git trees. I do that regularly, when development of some feature takes long time and checkin into SVN (actually here this is CC) is not possible due to possible breakage introduced by half-implemented feature. I keep intermediate results in git (and on some Unices in RCS) and when I'm ready I send the code to central repository (to avoid merges we use exclusive locks on files).
But please, do not let us distract you from going on to "Version Control in 21 days."
I frankly can't really enjoy Fx3 mainly due to two problems:
1. Time after time Mozilla would start doing something with disk and whole browser freezes, sometimes for as long as 10 seconds.
2. On bunch of sites Flash doesn't work. e.g. TheDailyShow.com
Due to Flash problems, I started using Opera now and -hey- 9.x series are not bad overall: very functional and no problems with Flash, no problems with interactivity.
I would be one of those unhappy about the change - tabs migrated from top to the left side (*). It added nothing new to the page while added something (occupying precious screen space) what I do not like.
Overall the change is bad. It is bad mostly because it is not optional. I spent half of an hour to try to put my tabs where they were before, but found no such option.
And since most of the Web sites are still not wide screen compatible, resizing my window wider is really annoying: on other sides I start to see more of the empty side bars. And it's not that on google.com/ig the space is occupied by something I need...
It's not the end of the world, but the change is bad.
(*) Also I think left-handed people would have preferred the tabs on right side of page. But you can't move them, you can't remove them.
ZOMG!!! Next thing you would doubt God!!!!! Inquisition!!!!! Somebody call Spanish Inquisition!!!!!
Seriously though, if you use cheap Asian made PC components (I use them 90% of time) and home built computers (I do that 100% of time) then you probably would never see FireWire.
But in markets where camcoders are norm of life, more or less all brand computers advertised with video editing feature have/had FireWire. Many friends, who never seen Mac before - but apparently heard about it more than I did - all were coming to me to use my iBook/iMovie with their DV cams. Windows' MovieMaker seems like never getting fixed, nor can it produce anything else but WMV.
Though frankly, I have never seen real advantage of FireWire. Yes, it is slightly faster, easier on CPU and better at sustained transfer rates. You can even have two/more transfers at the same time. Some time ago when RAM was expensive and implementing buffering on camcoder was prohibitively expensive, the real-time nature of FireWire had its uses. Now devices can routinely include megs of buffers to smooth transfers over USB. Unless properly wired, you still can't use two USB devices in parallel, though.
USB is crap of bus, but it costs nothing. And that allows for it to be in more devices than FireWire could have ever imagined.
[...] incorrect information from the faulty computer triggered a series of alarms [...]
Avionics is mission critical/life support stuff. That means all stuff - including darn cables - must detect errors. Triple (at least) redundancy is there for a reason - to go on working no matter what.
This will not only cause some heads rolling (figuratively speaking), but also in charges and very likely conviction. And this would be very easy to find: in avionics (like in all similar fields) all the review documents have signatures and very clear (and strict) distribution of responsibilities.
In RPG world, finding a weakness of your enemy and exploiting it is already a type of cheating.
Essentially any (winning) strategy can be also seen as cheating.
It's not that I have experience in cheating (it's only console folks cry about it all the time) but IMO there is a little difference between (1) using a cheat and (2) having a winning strategy/tactics.
Essential difference between the two is that presence of cheating means imbalanced game mechanics. Or even dumber case of engineers leaving a test loophole open in production version.
Nowadays, cheating is not problem anymore. It was never problem on PCs, since games could always patched or modded. It is not a problem on consoles now anymore since the games can be patched too - hard drive more or less a must on modern consoles.
Since this is Square Enix we're speaking here (read: old-timers, with legs firmly cemented in past) I wouldn't be all that surprised if in case of taking damage, electric shock would be send directly to your brain. Just to make sure that, you know, analogous to other SE RPGs, you are taking it seriously and in no case enjoying the game.
P.S. And obviously, as friendly guesture, you brains would be lobotomized if you die. To make sure that you can't cheat and all are on the same leveled play field.
In other words, Sun Inc. still has no clue as to precisely what it wants to do with its assets. And no clue what to do with other markets where they have accidentally became leader. Current strategy seems to be "play dead."
And the leakage of talented people from Sun, doesn't really give it a good mark as employer.
I've been asking about fork() in Strawberry Perl...
Though Perl is quite portable (I'm using it 8 years too (and actually started on Windows)) still, on *nix it feel at home.
Question about fork() was more or less theoretical. I have yet to ever run into need to use fork() in Perl - shell pipes all the way. Pipes under CygWin work but very slow due to slower process creation under Windows (I actually did trace that: CygWin's part is relatively fast, but the process creation in OS itself is slow (5-25ms)). And in case of Perl, starting new instance of perl might take some time. E.g. "whatever | while read A B C; do./aaa.pl C B A; done | whereever" runs into dozens millisecond just to spawn new perl instance.
A 100% Open Source CPAN-capable Perl for all your Windows® computers that works exactly the same as Perl everywhere else.
Does that mean it also has fork()?
But honestly, to me properly functioning select() (with both pipes and sockets) is already more than enough.
Though admittedly I do not have plans to go back to Windows.
I wouldn't elaborate on the all boring details, but just shortly summarize my experience.
If you can Perl, then you better off porting your stuff to Linux. Perl on Windows sounds cool and ActiveState does excellent job. But Perl would always remain underdog, restrained by the fact that its foreign platform - platform where VB rules.
I know I sound impractical, but after two years trying to make some stuff fly reliably on Windows with CygWin and ActiveState, I simply given up. I given up on Windows mostly because I found that all stuff I need, on Linux is very similar and (most importantly) there are no all those stupid CygWin and OLE/ActiveX annoyances and periodic breakages. For my application, near doubled performances was only an extra bonus.
If you plan to remain on Windows, you have to accept and start doing it in VB or C# or whatever is language du jour in Redmond.
If you depend on Perl, then thinking in direction of *nix platform is sound choice. (Or even some VMware or VBox setup with Linux guest.)
P.S. My work was related to processing of.xls files with huge amount of statistical data and making some charts for them. On Linux that was solved beautifully with (1) telling people to export info as CSV (extra bonus: smaller files) and (2) gnuplot output charts to PDF. Frankly, in the end it worked magnitudes better than the setup with ActiveState Perl/Excel/WinWord/etc on Windows.
If you have followed AMD for some time (and I have - I lived in Dresden for two years), you would know all the troubles associated with building a fan now.
For its first fab, AMD could pull it mostly on its own. Still there were some other parties in the deal. For seconds fab in Dresden it was much much more complicated: further improvements in manufacturing processes made fabs more expensive. $2Bln is quite number for smallish company like AMD to pull. And finding partners is quite hard, because many wouldn't like that AMD sits on two chairs and getting guarantees that your product will not stall somewhere in AMD's fab pipeline, preempted by urgent work for AMD itself (to compete with no less Intel itself), is impossible. Thus finding partners for new fab is very hard for monolithic AMD.
Short term it would of course suck. Bureaucracy and communication of design details can easily introduce unwanted delays.
In long term it would also suck. Competing with Intel which has dozen of fabs would be very hard. New manufacturing processes would be harder to sync with CPUs road map.
But that's of course much better than sitting with the fabs on your balance sheet: they quickly loose relevance and need to be scrapped and rebuild literally completely anew. And the old manufacturing process is not that really old and irrelevant: it is old for CPUs and GPUs (due to competitive pressure from Nvidia and Intel), yet can be used for bunch of other products. e.g. Xbox only recently went to 65nm, while ATI's 48x0 GPU family already enjoys 55nm process.
If this are lawsuits we're talking, somebody should charge M$ with false advertisement: many end-users were made to think that thanks to UAC Vista is more secure than XP.
FF franchise games are too boring. Story is good, visuals are excellent, sound is good - but the game core... suck. Not terribly - but enough to bore me to not to play them.
For one simple reason. Gov't procurement procedures still require to purchase standard compliant ware. If there is a national (e.g. ANSI, depending on your nationality) standard, then it is must be ANSI standard compliant. If there is no national standard - then ISO standards must be checked.
We all shouldn't forget why M$ got into the standards game at all. I'm sure it was discussed before here too: one US agency said it can not renew office suit licensing deal with M$ because there is not international standard (guess which *grin* *grin*) for document formats and M$Office isn't compatible with it. M$ partner was more than just surprised and reported to Redmond to pull some strings. IIRC scandal actually erupted when they singed deal anyway without even doing proper public tender, later making up excuses that they were not aware that there are other suppliers.
Slashdot Mirror
[...] it is hard to find any negative articles on PGP, probably because most of them are written by IT pros who are only focused on the security, and not usability.
What you mean they care not or usability"?????
What about the nice view on crematorium out of your safe and secure cell??? with the nice blue smoke of burning bodies of idiots who doubted guards abilities????? That high electrified barbed wire fence looks sooo sexy in the night under lights of nazi guards' lights. And in the concentration camp they also allow you whooping five(!!!) minute walk!!!!!
What could be better that be safe and under watchful eye of trained professionals???
P.S. On serious side though, you might have not found any sensible articles on PGP whole disk thing because nobody uses it. I knew couple of people in past who for that whole purpose were installing Linux. Yet, their setup was much much more saner: standard Linux setup (bunch of normal partitions) + encrypted partition for sensitive documents and /tmp + disabled swap (lots of memory was installed on the notebook specifically for the purpose).
Pretty much natural choice for all who can't (or refuses) to grok Perl, yet want to have a real language at their disposal.
That's flamebait.
Unintentional. I wrote it that way since Perl has been polarizing people: some love it, some hate it.
But frankly, if you look back in the times of PHP inception, Python wasn't there yet. It was still some toy language made by some guy called van Rossum to be used as educational tool. Perl was pretty much de facto language for Web. PHP provided templates for web pages what allowed to put some designers to do work without much understanding by using plain copy-pasting.
Now you already can't choose/change language easily as you could in past. Service libraries and frameworks - as per project requirements - pretty much define what language one would use. You wouldn't want to start every new project from ground zero. (N.B. The topic here is namespaces in PHP. The whole point of namespaces is to facilitate development of components.)
CGI days (only technical requirement is standard input and output) are long gone. You gonna end up with huge performance problems unless you would use something more modern and advanced than trivial piping. PHP, as something running inside web server, also put some nails into CGI coffin.
Hm... Thanks for the link. Enlightening reading.
Now I'm slowly getting why people even bother to use Python for Web. Pretty much natural choice for all who can't (or refuses) to grok Perl, yet want to have a real language at their disposal.
I used PHP around year 2000. It was simple like toy. But it seems that its developers didn't realize that the language did outgrow the sandbox they were living in. Also - the responsibility they carry before all the web developers who invested time into learning PHP.
It seems that the PHP developers had chosen path of M$VB.
You should say "thanks" they haven't chosen something else. e.g Jam (build system; make analog) uses "!" as a "platform neutral" path separator. During evaluations for new build system I joked that I oppose jam since we do not need a "platform neutral" system - we need one for *nix and cygwin. To my surprise many supported me.
I think their decision to use '\' is very very dumb one.
I'm still huge fan of Objective-C in that aspect. Unlike C++, which tried to marry C and objects, ObjC took more pragmatic approach: C constructs remains C constructs and object oriented constructs got new distinctive syntax so that you can never mix up what code you are looking at.
In that aspect, I think PHP folks would regret their decision in future: '\' isn't distinctive enough and they would need to introduce more silly syntax hacks when extending language further.
And yet, here we are, manufacturing the same damn problem for ourselves in Linux with Xorg default file location specifications, which really shouldn't be.
Simple idea came to my mind as I read your response.
That's what I was missing on Windows for quite some time: add a "Find a File" button to open/save file dialogs. (Yes, save file dialog also needs one for the case when one wants to save a new file along with another existing one or simply overwrite old file.) Clicking the button might toggle between picking a file and searching a file.
That solves problem for most "idiot" end-users (e.g. my parents being good example) who are only capable to learn and to work with one application (e.g. OOWriter).
For the children: please, don't do it.
I noticed that some children in fact has no problem using `find ~ -type f` - it is for their parents we need to come up with something.
We need a consistent experience across GNOME, KDE, OpenOffice and Firefox so that content can flow from app to app in a seamless fashion and the user's expectations can be met no matter which app or environment they happen to use.
In Windows we have survived several such attempts. e.g. "Recent File" or "Documents" in Start menu; or the useless location buttons in open/save file dialogs.
Let's just hope I would be still able to open a file at random location. Because the statement makes me feel that eventually I would be able to find all possible files - system thinks I may need to find, but not the files I actually need.
I've personally had the experience of trying to find a file for a customer who had just finished editing a critical report, saved it, and then couldn't locate it to deliver to their client.
Orienting future development on full idiots worked well in past... Or not? Well, GNOME full of it already and another drop of inusability into the mix will not hurt much its rabid fans.
As they say, give man a fish...
P.S. rfc1925, ch 11.
You seem to not read carefully the most important part: "Microsoft's engineers seem to be really committed to making Samba fully interoperable with AD"
M$ engineers are normal folks like you and me. Well, probably not me. The all cr*p breaks loose when M$ management gets involved and start pushing its political agendas.
If cooperation between AD and Samba folks would be successful, rest assured some M$ managers would try to stick themselves into the project to get a free share of credit for the success.
Whose bright idea was it to make the clientspec an unversioned artifact?
ClearCase has the same sickness.
We have periodic breakages since people routinely use wrong config_specs or simply make a typo there.
CC's dynamic views are no solution and even ten people compiling something in parallel overload one server very easily. And the fact that dynamic view doesn't allow you to select what to have in the view (you have always whole repo - like ... WHOLE F***ING REPOSITORY) is another plain suckage.
OTL
Did you ever tried to code yourself? You look/sound like idiot here.
General rule is quite simple: to thoroughly test code written in 1 day, you need 2 days. If you spent one week developing piece of code, to test it you would need at least another week. That's already two weeks without revision control.
This is sure recipe for disaster and some companies even have rules to checkin everything at the end of the day as to not to loose something to computer failure.
You can backup repositories on server - you can't backup everybody's hard drive.
We are all happy to acknowledge here that you have read "Version control for Dummies" book already and have plethora of theoretical advices for people who manage and do coding of huge codebases in large organizations.
On practical side, though, it seems you never actually tried to organize team out of two programmers. Because even two coders with same coding style following same rules would immediately declare that they want three branches: one main (to merge their work) and two for each other to work independently. In SVN having three branches is P.I.T.A. In git this is trivial. In SVN managers can control what devels do. In git - they can't. Consequently choice of SCM falls onto management and degree of control over developers you want to exercise. Generally, large organizations have too much organizational overhead leading to use of centralized systems like SVN. Git just adds to the management mess.
Practically feasible solution is hybrid to make everybody happy: use SVN on R&D (department) level; let teams maintain their own git trees. I do that regularly, when development of some feature takes long time and checkin into SVN (actually here this is CC) is not possible due to possible breakage introduced by half-implemented feature. I keep intermediate results in git (and on some Unices in RCS) and when I'm ready I send the code to central repository (to avoid merges we use exclusive locks on files).
But please, do not let us distract you from going on to "Version Control in 21 days."
But did Mozilla fix all the issues in Fx3??
I frankly can't really enjoy Fx3 mainly due to two problems:
1. Time after time Mozilla would start doing something with disk and whole browser freezes, sometimes for as long as 10 seconds.
2. On bunch of sites Flash doesn't work. e.g. TheDailyShow.com
Due to Flash problems, I started using Opera now and -hey- 9.x series are not bad overall: very functional and no problems with Flash, no problems with interactivity.
I would be one of those unhappy about the change - tabs migrated from top to the left side (*). It added nothing new to the page while added something (occupying precious screen space) what I do not like.
Overall the change is bad. It is bad mostly because it is not optional. I spent half of an hour to try to put my tabs where they were before, but found no such option.
And since most of the Web sites are still not wide screen compatible, resizing my window wider is really annoying: on other sides I start to see more of the empty side bars. And it's not that on google.com/ig the space is occupied by something I need...
It's not the end of the world, but the change is bad.
(*) Also I think left-handed people would have preferred the tabs on right side of page. But you can't move them, you can't remove them.
ZOMG!!! Next thing you would doubt God!!!!! Inquisition!!!!! Somebody call Spanish Inquisition!!!!!
Seriously though, if you use cheap Asian made PC components (I use them 90% of time) and home built computers (I do that 100% of time) then you probably would never see FireWire.
But in markets where camcoders are norm of life, more or less all brand computers advertised with video editing feature have/had FireWire. Many friends, who never seen Mac before - but apparently heard about it more than I did - all were coming to me to use my iBook/iMovie with their DV cams. Windows' MovieMaker seems like never getting fixed, nor can it produce anything else but WMV.
Though frankly, I have never seen real advantage of FireWire. Yes, it is slightly faster, easier on CPU and better at sustained transfer rates. You can even have two/more transfers at the same time. Some time ago when RAM was expensive and implementing buffering on camcoder was prohibitively expensive, the real-time nature of FireWire had its uses. Now devices can routinely include megs of buffers to smooth transfers over USB. Unless properly wired, you still can't use two USB devices in parallel, though.
USB is crap of bus, but it costs nothing. And that allows for it to be in more devices than FireWire could have ever imagined.
[...] incorrect information from the faulty computer triggered a series of alarms [...]
Avionics is mission critical/life support stuff. That means all stuff - including darn cables - must detect errors. Triple (at least) redundancy is there for a reason - to go on working no matter what.
This will not only cause some heads rolling (figuratively speaking), but also in charges and very likely conviction. And this would be very easy to find: in avionics (like in all similar fields) all the review documents have signatures and very clear (and strict) distribution of responsibilities.
In RPG world, finding a weakness of your enemy and exploiting it is already a type of cheating.
Essentially any (winning) strategy can be also seen as cheating.
It's not that I have experience in cheating (it's only console folks cry about it all the time) but IMO there is a little difference between (1) using a cheat and (2) having a winning strategy/tactics.
Essential difference between the two is that presence of cheating means imbalanced game mechanics. Or even dumber case of engineers leaving a test loophole open in production version.
Nowadays, cheating is not problem anymore. It was never problem on PCs, since games could always patched or modded. It is not a problem on consoles now anymore since the games can be patched too - hard drive more or less a must on modern consoles.
Since this is Square Enix we're speaking here (read: old-timers, with legs firmly cemented in past) I wouldn't be all that surprised if in case of taking damage, electric shock would be send directly to your brain. Just to make sure that, you know, analogous to other SE RPGs, you are taking it seriously and in no case enjoying the game.
P.S. And obviously, as friendly guesture, you brains would be lobotomized if you die. To make sure that you can't cheat and all are on the same leveled play field.
In other words, Sun Inc. still has no clue as to precisely what it wants to do with its assets. And no clue what to do with other markets where they have accidentally became leader. Current strategy seems to be "play dead."
And the leakage of talented people from Sun, doesn't really give it a good mark as employer.
I've been asking about fork() in Strawberry Perl...
Though Perl is quite portable (I'm using it 8 years too (and actually started on Windows)) still, on *nix it feel at home.
Question about fork() was more or less theoretical. I have yet to ever run into need to use fork() in Perl - shell pipes all the way. Pipes under CygWin work but very slow due to slower process creation under Windows (I actually did trace that: CygWin's part is relatively fast, but the process creation in OS itself is slow (5-25ms)). And in case of Perl, starting new instance of perl might take some time. E.g. "whatever | while read A B C; do ./aaa.pl C B A; done | whereever" runs into dozens millisecond just to spawn new perl instance.
Thanks for the info!
A 100% Open Source CPAN-capable Perl for all your Windows® computers that works exactly the same as Perl everywhere else.
Does that mean it also has fork()?
But honestly, to me properly functioning select() (with both pipes and sockets) is already more than enough.
Though admittedly I do not have plans to go back to Windows.
I have been in similar shoes some time ago.
I wouldn't elaborate on the all boring details, but just shortly summarize my experience.
If you can Perl, then you better off porting your stuff to Linux. Perl on Windows sounds cool and ActiveState does excellent job. But Perl would always remain underdog, restrained by the fact that its foreign platform - platform where VB rules.
I know I sound impractical, but after two years trying to make some stuff fly reliably on Windows with CygWin and ActiveState, I simply given up. I given up on Windows mostly because I found that all stuff I need, on Linux is very similar and (most importantly) there are no all those stupid CygWin and OLE/ActiveX annoyances and periodic breakages. For my application, near doubled performances was only an extra bonus.
If you plan to remain on Windows, you have to accept and start doing it in VB or C# or whatever is language du jour in Redmond.
If you depend on Perl, then thinking in direction of *nix platform is sound choice. (Or even some VMware or VBox setup with Linux guest.)
P.S. My work was related to processing of .xls files with huge amount of statistical data and making some charts for them. On Linux that was solved beautifully with (1) telling people to export info as CSV (extra bonus: smaller files) and (2) gnuplot output charts to PDF. Frankly, in the end it worked magnitudes better than the setup with ActiveState Perl/Excel/WinWord/etc on Windows.
If you have followed AMD for some time (and I have - I lived in Dresden for two years), you would know all the troubles associated with building a fan now.
For its first fab, AMD could pull it mostly on its own. Still there were some other parties in the deal. For seconds fab in Dresden it was much much more complicated: further improvements in manufacturing processes made fabs more expensive. $2Bln is quite number for smallish company like AMD to pull. And finding partners is quite hard, because many wouldn't like that AMD sits on two chairs and getting guarantees that your product will not stall somewhere in AMD's fab pipeline, preempted by urgent work for AMD itself (to compete with no less Intel itself), is impossible. Thus finding partners for new fab is very hard for monolithic AMD.
Short term it would of course suck. Bureaucracy and communication of design details can easily introduce unwanted delays.
In long term it would also suck. Competing with Intel which has dozen of fabs would be very hard. New manufacturing processes would be harder to sync with CPUs road map.
But that's of course much better than sitting with the fabs on your balance sheet: they quickly loose relevance and need to be scrapped and rebuild literally completely anew. And the old manufacturing process is not that really old and irrelevant: it is old for CPUs and GPUs (due to competitive pressure from Nvidia and Intel), yet can be used for bunch of other products. e.g. Xbox only recently went to 65nm, while ATI's 48x0 GPU family already enjoys 55nm process.
Oh wait this is some OTHER companies who use security as a scare threat via nagging messages to get you to buy software.
You mean M$ "scares" users with UAC to buy Vista? You got some problem with your logic.
Last time I was checking that trick didn't fly.
If this are lawsuits we're talking, somebody should charge M$ with false advertisement: many end-users were made to think that thanks to UAC Vista is more secure than XP.
FF franchise games are too boring. Story is good, visuals are excellent, sound is good - but the game core ... suck. Not terribly - but enough to bore me to not to play them.
NetBooks?? You are kidding me.
This is a real chance to get at home two 4870 X2 in CrossFire config - and not to go bankrupt on electricity bill. ^_^
For one simple reason. Gov't procurement procedures still require to purchase standard compliant ware. If there is a national (e.g. ANSI, depending on your nationality) standard, then it is must be ANSI standard compliant. If there is no national standard - then ISO standards must be checked.
We all shouldn't forget why M$ got into the standards game at all. I'm sure it was discussed before here too: one US agency said it can not renew office suit licensing deal with M$ because there is not international standard (guess which *grin* *grin*) for document formats and M$Office isn't compatible with it. M$ partner was more than just surprised and reported to Redmond to pull some strings. IIRC scandal actually erupted when they singed deal anyway without even doing proper public tender, later making up excuses that they were not aware that there are other suppliers.