Functional languages are fun and very nice. But they also have major problems when it comes to resource management, since they try to distant programmer from it (== "lazy programming").
And I'd really love to have some Haskel analog for high-performance needs.
In past my friend went from Prolog to C++ (went from academia to real world: there were nobody to pay for expensive Prolog compiler license) and after rewriting his stuff in C though he has noticed that performance dropped he also noticed that memory consumption dropped by factor of four - allowing him to easily cram more optimizations into C++ code making it (with gcc) about twice as fast as Prolog version with some high end highly parallelizing compiler.
And now to the point of Prolog to C++ conversion. My friend found literally hundreds easy to access libraries for C++ which allowed to build e.g. nice GUI visualizer for his pet project. Something he didn't even dreamed of on Prolog: it was possible but all GUI libraries were poor and complicated to program .
The point is that academia keeps the functional languages slaves to their niche tasks very often forgetting that for language to be relevant to real world it also has to have many many libraries to solve all the particular real world problems and to solve them efficiently.
But right now, most such languages, when faced with new real world problem.... Well it just happen that they make another language to solve that particular problem.
If dumped in the air as N2 one would hope precautions against exposure to high concentrations are going to be stringent.
Actually my first reaction was that they removed N2 to avoid it pass through burning chambers. As much as N2 is nonreactive, yet some small part of it under not so high temperatures can oxidize, producing both NO and NO2. Forgot which of them, but one of them is considered toxic anther is simply harmful. e.g. the pollution map uses concentration of nitrous oxide as an index.
Exposure to high concentrations of N2 (which is plain asphyxiation) can be avoided easily - easily compared to actual lack of any methods extracting the potentially harmful oxides from air.
Can rejected patent application be used as a precedent during patent trial case?
Bit on off-topic side of course. But does it make sense for company to simply file patents for all the stuff which isn't yet patented. If it is rejected - then nobody can sue us for the use of idea since it cannot be patented. If it is accepted - well nobody can sue us for other obvious reason.
As a non-US guy's question: could such practice exist in US? (Because that might a good direction to work on for F/LOSS software to build-up a warchest^Wportfolio to protect itself from possible allegations.)
Or USPTO dumbly rubber-stamps everything it comes across of?
"Open" in business denotes that other businesses are also allowed participate. And OpenGL was in that sense "open": many used the library, many contributed extensions and features.
As library - it is (was?) proprietary closed source. As standard - it is open.
I understand that's question to different department. But still.
Does VIA intends to promote and produce further Mini/Pico-ITX mainboards?
What I'm really missing is barebone PCs based on such mainboards. There is a whole zoo of component - but they are not always compatible. In my case, for example, I found a good case for Mini-ITX I wish to buy - now the problem is that I can't find Mini-ITX mobos which are as per spec are compatible with it. Apparently physical measurements of the Mini/Pico-ITX are not completely standardized or are not sufficient to cover all what other manufacturers want to throw into the mix.
Also, Mini/Pico-ITX lacks its own spec for power supplies. The ones shipped with cases are often of bad quality (or overhear or too noisy).
Does VIA intends to start selling complete Mini/Pico-ITX solutions? Something I need to throw in only hard drive/RAM/etc - and I have a ready system.
Can anybody explain me why AMD still has tops 1MB cache per core? And this is on Opterons. Normal AM/AM+ CPUs have only 512K cache per core. Intel now has 4MB of cache per core on its workstation CPUs.
I can not understand why AMD doesn't increase cache size, while it's obvious that cache helps tremendously on memory intensive operations. Smaller caches are not even offset by its integrated on CPU memory controller.
I'm planning upgrade and though I like AMD price/performance ratio, even for modest workstation Intel is better choice - simply because their CPUs have more cache.
I still do not get his problem. (you say I should RTFA?? Nonsense.)
OpenGL, in the times when I wanted to learn it, was running perfectly on CPU. In fact rendering quality was (and remains) above that of H/W accelerated. Problem is that rendering goes from "frames-per-seconds" into "seconds-per-frame" performance range.
Parallelism in OpenGL was implemented several times before (SGI, 3D Labs; limited to 2 CPUs) so I think it can be done again and for more CPUs/cores. (*)
DirectX might have a problem though, because it is very very H/W oriented when it comes to 3D. (Though SLI works somehow!?)
(*) OpenGL has single-threaded API. But rendering itself doesn't have to be limited to one thread internally.
Before requesting SVN on SF.net was quite retarded. (Dunno now, didn't tried that in a while.) I was going to abandon one project (simple Solitaire for Mac OS X - due to loss of my iBook) and wanted to make sure that source code would survive.
Procedure of requesting SVN repo was something like that: (1) send request to SF.net pointing which project you want to host (filling piles and piles of tiny bits of information in the process: coming up with another set of unique names is always taking time) and the review might take some days/weeks, (2) wait for their negative/positive response from request review, (3) go thru another painful procedure actually activating (initiating) the repo with first sources. Everything is described in documentation. Procedure is not easiest, yet benefits do outweigh the pains doing it once.
But in my case it went like that: I did step (1) and waited for the response. None came. Three weeks later, I checked project management web interface and found that my request was granted within couple of hours after I send in details. No mail, no notification of any sort. Now to the worst part: since I didn't activated the service I have requested within two weeks after the grant, it was automatically canceled.
Facing opportunity to waste another couple of hours coming up with another set of unique names for everything, I given up and simply made another release of Solitaire with zipped source code in application bundle (hidden inside executable) itself.
I think, Google can't beat SF.net to such painful procedure. It can't be worse than that.
[...] if you somehow publish the record that you are doing it - Google would do the rest for you.
Forgot to mention a not really fitting example of how Web search is effective.
Some time ago I was literally driven nuts by one new feature of VIM. I spent some time digging and after many attempts found a solution: how to disable the feature.
So I have published on my blog (that was three years ago) a half-inflammatory post about where the hell modern text editors are headed to with the solution to my problem. Google did the rest: now the post has about 30 comments, most of which are "Thanks for info" ones. And I did precisely nothing to promote that I have found a solution to that particular problem.
So somehow publishing your idea with implementation sketch - even on blog - is a good start.
SF.net is also good place and I used it successfully several times. It works really well for making releases. With source code hosting I had some problems. Posting news there (or more to the point: finding something posted on SF.net) is not simple, so I would advise to use some simple blog for your pet project. (Or probably by now SF.net has some service similar to blogs.)
I have on my back-up drive about 30 half-dead projects I did for different purposes. Few of them are usable. Many of them were merely proof-of-concept stuff. Probably none of them has any new ideas.
I'd say, Web search engines now are the most impeding factor for programmer's ego: whatever brilliant idea one could possibly come up, some research shows that it is not new. Or it was tried before and failed. Or you have already in Debian repo a ready tool to do the work.
I do not know how to attract people to projects. All I can say (from my personal experience) it is pointless to try to attract people actively (but I say that in real life too - and I'm still single).
Best one can do is to keep working on idea (regardless of what Google says). If you really persistent, if you somehow publish the record that you are doing it - Google would do the rest for you. Point is that other programmers might stick with some active project simply out of curiosity. And after some time, if project still interests them, they might also contribute. That's how many projects have started. The most important bit here: somebody has to be ready to be a center of project and also has to work actively on the project. Others have to have something to tag along with.
P.S. Another parallel from real life. It is often said that (as opposed to women) there is no friendship among men. They just happen to look and go in the same direction. Or to the programming: if you keep developing idea in direction others can follow you, other would follow you - accidentally.
ITs are suffering from generic problem. (Correction: users are suffering, it is of course not IT's concern.) It's not that they do not understand what they are managing.
The problem goes much deeper: IT never really knows what for and how IT resources are really used by people who actually do work.
IT always concentrates on its end of job.
Results are obvious: horrifying end user stories about lost data, lost hours of work and IT which simply can't give any sensible response in emergencies.
Problem as I see it: whatever company is, IT is always way too far from real work: real work company is doing and earning money with.
My idea was always that IT has to be not department, but people spread all over the company. You need about 1 dedicated guy to be responsible for communication with suppliers (or probably somebody from Purchases can handle it - they handle it (monetarily) anyway). Rest has to be managed by teams themselves. They can have a dedicated guy(s) for the IT needs. Or one/more people on team can handle as part-time job the problems and etc.
As R&D guy, I yet to see a competent IT guy who can competently set up *nix server which after reboot is ready to work. Piles of certificates from lengthy trainings do not help them in real life. Outside of checking cables and phoning suppliers - I've seen no use to IT. And phoning/checking I can do myself. No big deal.
parent, grandparent posts - thank for info. I'll try that next time.
P.S.
I don't get it why samba isn't configured to let you login with you normal username/password... it's just a matter of altering smb config...
More than once thought crossed my mind: M$ paid Canonical (and others) to ensure that Linux would remain as unusable to end users as it is right now. Security nazis who cannot imagine firewalled home LAN are ruling.
BTW, same goes to FTPD default configuration (all of them - I tries all of them in Ubuntu: proftpd, vsftpd, wuftpd, etc). Only worse: valid logins are forbidden, SSL disabled/not available, anonymous can connect and read whole file system.
Point is that despite bunch of problems, FTP is probably fastest protocol for LANs and hey it supports Unix logins out of box - no mess with smbpasswd required. And even with SSL it is also faster than SSH's SFTP. SMB isn't much better than FTP because they still send in many situations passwords in plain text.
The main difference between SMB/NBIOS/WINS discovery (Windows Network) and FTP/SFTP/ZeroConf discovery (what I call Linux Network) is that later works reliably while former works depending on weather in a town 50 miles away (actually depending on configuration of nearby Windows server what is very very bad on my book; but I have to test that again anyway).
Try bugging Mozilla/FireFox people. Many proposals (patches included) were thrown on table - none accepted. To make things worse, Mozilla remade the code in Fx3 making all previous patches obsolete and the method used before by the extensions isn't supported anymore. Security reasons were cited.
I was always under impression that the people behind many projects do not really understand what kind of things normal end users are doing with computers. FireFox is not exception. Whole Ubuntu/GNOME is build around concept that user is an idiot who doesn't know why he has just forked $$$ for the PC.
I'm for example literally every month is called by some new Linux user who asks how to exchange files effectively between Linux boxes. In Windows there is "Windows Network." But in Linux - in most advanced desktop distro Ubuntu - the easiest method... right - e-mail. Sending from one PC to another, hooked over LAN, through some servers thousands miles away. Why not? [/sarcasm] Setting up (not installed by default) FTPd/OpenSSH/Avahi - is not something I can advise to end users to install setup by default. And the [censored] over there in Ubuntu really have no clue, writing off everything on "security via obscurity". As if sending confidential data over 3rd party is safer than sending them over LAN...
Your point is moot. Microkernels are dead for sometime already. For simple reason that they fit no niche. And if they fit - it is so narrow niche which falls out of general market.
On the point, Mac OS X uses microkernel. But only for simple reason to sync two kernels: NeXT kernel (heavily hacked IIRC BSD4.3lite) and FreeBSD (further development branch of BSD386/BSD4.2).
Mac OS GUI is essentially port of NeXT Step. All the fancy stuff you see on screen is based on improved specifically for Mac OS X NeXT frameworks. All APIs have "NS" prefix for the reason.
Now FreeBSD appeared for sole reason to ease new platform adoption and provide developers with familiar environment and tools. Apple didn't wanted to go the way of M$ and reinvent everything (and they had no money for that at the time) so they simply took existing OS and integrated that into Mac OS X. Brilliant idea IMNSHO (especially if compared to all possible alternatives).
Mac OS X has two kernels. And they are glued together by simple microkernel, which IMHO (never really bothered to check) would never classify as microkernel on book of real microkernel developers. It is micro only by its size and number of functions it performs. I can say for sure that drivers are not separate processes - as well as OS services - all that makes the Mac OS X not a microkernel OS.
Microsoft has no control over the shit quality of drivers released by hardware manufacturers.
I'm not sure I would go so far as to say they have zero control over that situation. Apple would not be a fair comparison since they control both the hardware and the software. [...] The Windows approach is demonstrably inferior in this case, and I just don't believe that Microsoft is the pitiful helpless victim that's powerless to change this.
You asking wrong question and reaching wrong conclusion.
Real question is: why driver development under Windows is such hurdle? Why some companies have to go as far as to developer their own DDKs for Windows??
M$ is guilty by making development complicated and constantly changing device driver model as to make it incompatible with previous versions of OS and force everybody to upgrade to newer versions.
They have no control over the shit quality of apps loaded by OEMs.
That certainly is true, but then, why should so many user applications have the ability to affect the rest of the operating system?
Damm, again wrong question and wrong conclusion. (Though in this case you have a good technical point. Linux would never allow any piece of software to cause as much troubles as Windows software is capable of.)
Real question is: why the OEMs have to preload anything at all? even if they know that it decrease quality??
Aha! Because they can get slashed few bucks (== decrease price) from 3rd parties. Now let's look at the list of most expensive parts of modern PC........ Hm... Why we find "M$Windows" close to the top/on the top of the list??? And why this coincides with M$ being convicted monopolist and many cases about overcharging????
M$ still didn't managed to diversify profit sources as much as they want and Windows remains one of its the major "cache cows". That's why in the market (where Apple and Linux's growth now in double digits) M$ still has to charge premium (and often overcharge) for its OS. Despite the fact that as an OS, technically it's lagging behind competition.
Threads historically were expensive because historically nobody used them. E.g. on Windows IO multiplexing had some history of bugs and didn't worked in the beginning - you had to use threads (and people used to use threads and even now use threads instead of NT's IO multiplexing). On *nix IO multiplexing worked more like always thus threads were (and are) used rarely.
Now, since number of CPUs increased dramatically in recent years, threads were optimized to be fast: developers now throw them as panacea at any task at hand. (Most stupid use of threads seen in the month: start new thread for every child application to wait for its termination; due to stupid code, it still might miss its termination).
As a system developer, I have went trhu user space parts of Linux 2.6 and Solaris 10 threads implementations (in disassembler; x64 and SPARC64 respectively) and can say that they are implemented well. (I was looking for example of atomic ops implementation.) Kernel parts of both Linux and Solaris are well known to perform extremely well, since they were tuned to support extremely large Java applications (and Java only now got IO multiplexing - before that threads were only option to perform multiple IO tasks simultaneously). HP-UX 11.x also didn't showed any abnormalities during internal benchmarks and generally its implementation is faster than that of Solaris 10 (after leveling results using speed of CPUs; SPARC64 vs. Itanic 2).
But I guess "slow *nix threads" is now the myth of the same kind as "slow Windows process creation." (Problem is of course that process creation in Windows would always remains expensive compared to *nix. But not that those millisecons of difference matter much for desktop applications.)
Since I work normally in R&Ds, my story is slightly different.
1. People often ask questions: per e-mail, per phone or personally coming to my office.
2. I myself also has to ask questions often, what is also distraction. (And in larger companies, with generally disorganized source code structure, you have to ask question more often.)
Delaying e-mail processing is also often doesn't help. Most mails have some sort of dead-line (hours, days) attached to them. Miss dead-line and some stupid error in your area would go into spec, like domino causing even greater damage later.
Worst case is of course if somebody needs my input during conf call. It's kind of when you are not invited to canf call, but your manager warns that if question related to my work would come up, they would call me. It is pretty much impossible to concentrate on any large piece of work, when you know that you might be interrupted any minute. Is such cases, I often find myself doing nothing else but checking e-mail...
Running each instance in a separate process is NOT new technology [...]
True, *nix does that for last 3 decades.
The point here (and of RTFA) is that finally on Windows processes are becoming cheaper, making them usable for all the nasty stuff *nix was indulging itself for all the time.
On NT 3.5, creation of new process was taking sometime as long as 300ms. Imaging Chrome on NT: if you open three tabs and start three new processes, on NT in the times, that alone would have taken about one second.
Unix never had the problem. It's Windows specific. And they are improving.
In corporations, you have to react to e-mail fast. That's why people check it often.
I'd say working in large companies is more dangerous (and distracting) than e-mail itself.
Working for smaller companies, I never had problems writing 1000+ lines of code per day. Working in large companies, I have to stay after 6pm to be able to concentrate at all. And e-mail, believe me, is least of the distractions.
Redhat has a reputation for leading the industry and releasing quality products in the past.
You either: never used RH or used only RH.
RH has two major sicknesses.
1. Pushing untested alpha, unversioned(!) stuff on their customers. glibc and gcc pretty much always bear "CVS112234433435343" monikers instead of real versions. Number of applied patches to some program make most version numbers pretty meaningless.
2. "Not invented here" syndrom. SuSE did something for many years. Debian did something for many years. Users even ported that over to RH. Next version we see that RH finally woke up and... right: disregarded everything what already there and build something from scratch. See #1 why it never worked and took couple of version for them to stabilize the software. ("2 service packs before deployment" rule from Windows world was and is also applicable to RH.)
Not that I have something against system I have to use occasionally, but pretty much everybody I know who runs RH (be it Fedora or RHEL) runs it for one sole reason: "we have to, our bigger partners are using it." I yet to meet single person who uses OS from RH for some other reasons.
And hey! It worked!! For at least one company: Apple
Though I think Apple's reasons were quite different from being lobbied. Jobs once quoted saying that it's not his work to do products. His work is to keep business out of way of the engineers who do the products.
Apple got many young graduates, many of whom worked before and grew up on Linux and BSD. And of course the people had something for F/LOSS and I personally think that Apple really understood the fact that most software layers in modern computers are pretty much standardized so it make no sense to reinvent the wheel. But what make sense is to try to take advantage of all what was already developed out there. Contributing back is also no-brainer and take little of time, while giving developers (otherwise hidden deep in corporate org-charts) some visible credit.
Case of TiVo is very different from RH's one. And for TiVo, as end user you have alternative to build your own appliance with MythTV. TiVo tries to protect its hardware on one side and follow its contract obligations to content distributors on another.
With RH's governance and support strict guidelines, many users found themselves in situation they were with commercial *nices: do not touch anything, do not change anything, wait for us to do it.
Having source code for RH is already meaningless, because if you would change something, they would (very likely) refuse to support you.
With small/medium business being largest (by user count) user of RH, its focus on Fortune 100 companies, screws royally everybody else. And as small/medium business, you would never ever get the same treatment from RH as its Fortune 100 customers.
Another difference is that nobody forces you to buy TiVo. But many companies literally have to use Fedora/buy RHEL because they have to be compatible with software stack their bigger partners are using. And running the same software is easiest way to accomplish that and only way which guarantees 100% trouble free relationships. That again is major regression from F/LOSS to ways of old proprietary *nices and M$Windows.
From my knowledge of such contracts, you could never really sue software provider. Exceptions are mission critical and life support systems. (By mission critical I mean real mission critical - not "business critical". e.g. avionics.)
From my experience, most problems come from hardware. And biggest problem is always to properly in hardware to handle such errors. And hardware set-up plays tremendous role in such deployments. You have probably 5-10 pieces of software to test and some thousands hardware devices compromising the whole infrastructure. Failure rate of hardware is obviously higher.
Well, seven hours, at least to me, look like Windows Server said it wants to update. After update all other said "bueh!" and demanded to be updated too. MS has a history of updates with requirement of simultaneous update of *all* servers across your network. He-he... 5 nines... Good luck.
SecuROM disallows me to play any game, unless I physically disconnect my Plextor DVD burner... Went through lots of pains when trying to install/play Quake 4.
In business, generally it means that solution provider (software + hardware) bears direct responsibility for all unplanned downtimes.
If solution cannot provide such service availability, the solution provider has to be ready to cover all the damages. And it is often planned that way from day one: some downtimes are covers by the "5 nines", some are covered monetarily by solution providers.
That's why 5 nines solutions cost as much as they cost: on one side to allow providers to bring quality of solution to desired level, on another side, in case of emergency, to let them to cover some downtimes with money.
But covering seven(!) hours(!!) can be lethal to the solution provider. But again, it all depends on their support contract. Some (cheaper) 5 nines are delivered without any guarantees: they only theoretically 5 nines and provide only "best effort" service availability.
Slashdot Mirror
I second.
Functional languages are fun and very nice. But they also have major problems when it comes to resource management, since they try to distant programmer from it (== "lazy programming").
And I'd really love to have some Haskel analog for high-performance needs.
In past my friend went from Prolog to C++ (went from academia to real world: there were nobody to pay for expensive Prolog compiler license) and after rewriting his stuff in C though he has noticed that performance dropped he also noticed that memory consumption dropped by factor of four - allowing him to easily cram more optimizations into C++ code making it (with gcc) about twice as fast as Prolog version with some high end highly parallelizing compiler.
And now to the point of Prolog to C++ conversion. My friend found literally hundreds easy to access libraries for C++ which allowed to build e.g. nice GUI visualizer for his pet project. Something he didn't even dreamed of on Prolog: it was possible but all GUI libraries were poor and complicated to program .
The point is that academia keeps the functional languages slaves to their niche tasks very often forgetting that for language to be relevant to real world it also has to have many many libraries to solve all the particular real world problems and to solve them efficiently.
But right now, most such languages, when faced with new real world problem .... Well it just happen that they make another language to solve that particular problem.
If dumped in the air as N2 one would hope precautions against exposure to high concentrations are going to be stringent.
Actually my first reaction was that they removed N2 to avoid it pass through burning chambers. As much as N2 is nonreactive, yet some small part of it under not so high temperatures can oxidize, producing both NO and NO2. Forgot which of them, but one of them is considered toxic anther is simply harmful. e.g. the pollution map uses concentration of nitrous oxide as an index.
Exposure to high concentrations of N2 (which is plain asphyxiation) can be avoided easily - easily compared to actual lack of any methods extracting the potentially harmful oxides from air.
Can rejected patent application be used as a precedent during patent trial case?
Bit on off-topic side of course. But does it make sense for company to simply file patents for all the stuff which isn't yet patented. If it is rejected - then nobody can sue us for the use of idea since it cannot be patented. If it is accepted - well nobody can sue us for other obvious reason.
As a non-US guy's question: could such practice exist in US? (Because that might a good direction to work on for F/LOSS software to build-up a warchest^Wportfolio to protect itself from possible allegations.)
Or USPTO dumbly rubber-stamps everything it comes across of?
"Open" in business denotes that other businesses are also allowed participate. And OpenGL was in that sense "open": many used the library, many contributed extensions and features.
As library - it is (was?) proprietary closed source. As standard - it is open.
I understand that's question to different department. But still.
Does VIA intends to promote and produce further Mini/Pico-ITX mainboards?
What I'm really missing is barebone PCs based on such mainboards. There is a whole zoo of component - but they are not always compatible. In my case, for example, I found a good case for Mini-ITX I wish to buy - now the problem is that I can't find Mini-ITX mobos which are as per spec are compatible with it. Apparently physical measurements of the Mini/Pico-ITX are not completely standardized or are not sufficient to cover all what other manufacturers want to throw into the mix.
Also, Mini/Pico-ITX lacks its own spec for power supplies. The ones shipped with cases are often of bad quality (or overhear or too noisy).
Does VIA intends to start selling complete Mini/Pico-ITX solutions? Something I need to throw in only hard drive/RAM/etc - and I have a ready system.
Can anybody explain me why AMD still has tops 1MB cache per core? And this is on Opterons. Normal AM/AM+ CPUs have only 512K cache per core. Intel now has 4MB of cache per core on its workstation CPUs.
I can not understand why AMD doesn't increase cache size, while it's obvious that cache helps tremendously on memory intensive operations. Smaller caches are not even offset by its integrated on CPU memory controller.
I'm planning upgrade and though I like AMD price/performance ratio, even for modest workstation Intel is better choice - simply because their CPUs have more cache.
I still do not get his problem. (you say I should RTFA?? Nonsense.)
OpenGL, in the times when I wanted to learn it, was running perfectly on CPU. In fact rendering quality was (and remains) above that of H/W accelerated. Problem is that rendering goes from "frames-per-seconds" into "seconds-per-frame" performance range.
Parallelism in OpenGL was implemented several times before (SGI, 3D Labs; limited to 2 CPUs) so I think it can be done again and for more CPUs/cores. (*)
DirectX might have a problem though, because it is very very H/W oriented when it comes to 3D. (Though SLI works somehow!?)
(*) OpenGL has single-threaded API. But rendering itself doesn't have to be limited to one thread internally.
Before requesting SVN on SF.net was quite retarded. (Dunno now, didn't tried that in a while.) I was going to abandon one project (simple Solitaire for Mac OS X - due to loss of my iBook) and wanted to make sure that source code would survive.
Procedure of requesting SVN repo was something like that: (1) send request to SF.net pointing which project you want to host (filling piles and piles of tiny bits of information in the process: coming up with another set of unique names is always taking time) and the review might take some days/weeks, (2) wait for their negative/positive response from request review, (3) go thru another painful procedure actually activating (initiating) the repo with first sources. Everything is described in documentation. Procedure is not easiest, yet benefits do outweigh the pains doing it once.
But in my case it went like that: I did step (1) and waited for the response. None came. Three weeks later, I checked project management web interface and found that my request was granted within couple of hours after I send in details. No mail, no notification of any sort. Now to the worst part: since I didn't activated the service I have requested within two weeks after the grant, it was automatically canceled.
Facing opportunity to waste another couple of hours coming up with another set of unique names for everything, I given up and simply made another release of Solitaire with zipped source code in application bundle (hidden inside executable) itself.
I think, Google can't beat SF.net to such painful procedure. It can't be worse than that.
[...] if you somehow publish the record that you are doing it - Google would do the rest for you.
Forgot to mention a not really fitting example of how Web search is effective.
Some time ago I was literally driven nuts by one new feature of VIM. I spent some time digging and after many attempts found a solution: how to disable the feature.
So I have published on my blog (that was three years ago) a half-inflammatory post about where the hell modern text editors are headed to with the solution to my problem. Google did the rest: now the post has about 30 comments, most of which are "Thanks for info" ones. And I did precisely nothing to promote that I have found a solution to that particular problem.
So somehow publishing your idea with implementation sketch - even on blog - is a good start.
SF.net is also good place and I used it successfully several times. It works really well for making releases. With source code hosting I had some problems. Posting news there (or more to the point: finding something posted on SF.net) is not simple, so I would advise to use some simple blog for your pet project. (Or probably by now SF.net has some service similar to blogs.)
I have to second the comment.
I have on my back-up drive about 30 half-dead projects I did for different purposes. Few of them are usable. Many of them were merely proof-of-concept stuff. Probably none of them has any new ideas.
I'd say, Web search engines now are the most impeding factor for programmer's ego: whatever brilliant idea one could possibly come up, some research shows that it is not new. Or it was tried before and failed. Or you have already in Debian repo a ready tool to do the work.
I do not know how to attract people to projects. All I can say (from my personal experience) it is pointless to try to attract people actively (but I say that in real life too - and I'm still single).
Best one can do is to keep working on idea (regardless of what Google says). If you really persistent, if you somehow publish the record that you are doing it - Google would do the rest for you. Point is that other programmers might stick with some active project simply out of curiosity. And after some time, if project still interests them, they might also contribute. That's how many projects have started. The most important bit here: somebody has to be ready to be a center of project and also has to work actively on the project. Others have to have something to tag along with.
P.S. Another parallel from real life. It is often said that (as opposed to women) there is no friendship among men. They just happen to look and go in the same direction. Or to the programming: if you keep developing idea in direction others can follow you, other would follow you - accidentally.
[...] you can't manage what you don't understand.
ITs are suffering from generic problem. (Correction: users are suffering, it is of course not IT's concern.) It's not that they do not understand what they are managing.
The problem goes much deeper: IT never really knows what for and how IT resources are really used by people who actually do work.
IT always concentrates on its end of job.
Results are obvious: horrifying end user stories about lost data, lost hours of work and IT which simply can't give any sensible response in emergencies.
Problem as I see it: whatever company is, IT is always way too far from real work: real work company is doing and earning money with.
My idea was always that IT has to be not department, but people spread all over the company. You need about 1 dedicated guy to be responsible for communication with suppliers (or probably somebody from Purchases can handle it - they handle it (monetarily) anyway). Rest has to be managed by teams themselves. They can have a dedicated guy(s) for the IT needs. Or one/more people on team can handle as part-time job the problems and etc.
As R&D guy, I yet to see a competent IT guy who can competently set up *nix server which after reboot is ready to work. Piles of certificates from lengthy trainings do not help them in real life. Outside of checking cables and phoning suppliers - I've seen no use to IT. And phoning/checking I can do myself. No big deal.
But probably that's only me who is that unlucky.
parent, grandparent posts - thank for info. I'll try that next time.
P.S.
I don't get it why samba isn't configured to let you login with you normal username/password... it's just a matter of altering smb config...
More than once thought crossed my mind: M$ paid Canonical (and others) to ensure that Linux would remain as unusable to end users as it is right now. Security nazis who cannot imagine firewalled home LAN are ruling.
BTW, same goes to FTPD default configuration (all of them - I tries all of them in Ubuntu: proftpd, vsftpd, wuftpd, etc). Only worse: valid logins are forbidden, SSL disabled/not available, anonymous can connect and read whole file system.
Point is that despite bunch of problems, FTP is probably fastest protocol for LANs and hey it supports Unix logins out of box - no mess with smbpasswd required. And even with SSL it is also faster than SSH's SFTP. SMB isn't much better than FTP because they still send in many situations passwords in plain text.
The main difference between SMB/NBIOS/WINS discovery (Windows Network) and FTP/SFTP/ZeroConf discovery (what I call Linux Network) is that later works reliably while former works depending on weather in a town 50 miles away (actually depending on configuration of nearby Windows server what is very very bad on my book; but I have to test that again anyway).
Try bugging Mozilla/FireFox people. Many proposals (patches included) were thrown on table - none accepted. To make things worse, Mozilla remade the code in Fx3 making all previous patches obsolete and the method used before by the extensions isn't supported anymore. Security reasons were cited.
I was always under impression that the people behind many projects do not really understand what kind of things normal end users are doing with computers. FireFox is not exception. Whole Ubuntu/GNOME is build around concept that user is an idiot who doesn't know why he has just forked $$$ for the PC.
I'm for example literally every month is called by some new Linux user who asks how to exchange files effectively between Linux boxes. In Windows there is "Windows Network." But in Linux - in most advanced desktop distro Ubuntu - the easiest method ... right - e-mail. Sending from one PC to another, hooked over LAN, through some servers thousands miles away. Why not? [/sarcasm] Setting up (not installed by default) FTPd/OpenSSH/Avahi - is not something I can advise to end users to install setup by default. And the [censored] over there in Ubuntu really have no clue, writing off everything on "security via obscurity". As if sending confidential data over 3rd party is safer than sending them over LAN...
Your point is moot. Microkernels are dead for sometime already. For simple reason that they fit no niche. And if they fit - it is so narrow niche which falls out of general market.
On the point, Mac OS X uses microkernel. But only for simple reason to sync two kernels: NeXT kernel (heavily hacked IIRC BSD4.3lite) and FreeBSD (further development branch of BSD386/BSD4.2).
Mac OS GUI is essentially port of NeXT Step. All the fancy stuff you see on screen is based on improved specifically for Mac OS X NeXT frameworks. All APIs have "NS" prefix for the reason.
Now FreeBSD appeared for sole reason to ease new platform adoption and provide developers with familiar environment and tools. Apple didn't wanted to go the way of M$ and reinvent everything (and they had no money for that at the time) so they simply took existing OS and integrated that into Mac OS X. Brilliant idea IMNSHO (especially if compared to all possible alternatives).
Mac OS X has two kernels. And they are glued together by simple microkernel, which IMHO (never really bothered to check) would never classify as microkernel on book of real microkernel developers. It is micro only by its size and number of functions it performs. I can say for sure that drivers are not separate processes - as well as OS services - all that makes the Mac OS X not a microkernel OS.
I'm not sure I would go so far as to say they have zero control over that situation. Apple would not be a fair comparison since they control both the hardware and the software. [...] The Windows approach is demonstrably inferior in this case, and I just don't believe that Microsoft is the pitiful helpless victim that's powerless to change this.
You asking wrong question and reaching wrong conclusion.
Real question is: why driver development under Windows is such hurdle? Why some companies have to go as far as to developer their own DDKs for Windows??
M$ is guilty by making development complicated and constantly changing device driver model as to make it incompatible with previous versions of OS and force everybody to upgrade to newer versions.
That certainly is true, but then, why should so many user applications have the ability to affect the rest of the operating system?
Damm, again wrong question and wrong conclusion. (Though in this case you have a good technical point. Linux would never allow any piece of software to cause as much troubles as Windows software is capable of.)
Real question is: why the OEMs have to preload anything at all? even if they know that it decrease quality??
Aha! Because they can get slashed few bucks (== decrease price) from 3rd parties. Now let's look at the list of most expensive parts of modern PC........ Hm... Why we find "M$Windows" close to the top/on the top of the list??? And why this coincides with M$ being convicted monopolist and many cases about overcharging????
M$ still didn't managed to diversify profit sources as much as they want and Windows remains one of its the major "cache cows". That's why in the market (where Apple and Linux's growth now in double digits) M$ still has to charge premium (and often overcharge) for its OS. Despite the fact that as an OS, technically it's lagging behind competition.
Threads historically were expensive because historically nobody used them. E.g. on Windows IO multiplexing had some history of bugs and didn't worked in the beginning - you had to use threads (and people used to use threads and even now use threads instead of NT's IO multiplexing). On *nix IO multiplexing worked more like always thus threads were (and are) used rarely.
Now, since number of CPUs increased dramatically in recent years, threads were optimized to be fast: developers now throw them as panacea at any task at hand. (Most stupid use of threads seen in the month: start new thread for every child application to wait for its termination; due to stupid code, it still might miss its termination).
As a system developer, I have went trhu user space parts of Linux 2.6 and Solaris 10 threads implementations (in disassembler; x64 and SPARC64 respectively) and can say that they are implemented well. (I was looking for example of atomic ops implementation.) Kernel parts of both Linux and Solaris are well known to perform extremely well, since they were tuned to support extremely large Java applications (and Java only now got IO multiplexing - before that threads were only option to perform multiple IO tasks simultaneously). HP-UX 11.x also didn't showed any abnormalities during internal benchmarks and generally its implementation is faster than that of Solaris 10 (after leveling results using speed of CPUs; SPARC64 vs. Itanic 2).
But I guess "slow *nix threads" is now the myth of the same kind as "slow Windows process creation." (Problem is of course that process creation in Windows would always remains expensive compared to *nix. But not that those millisecons of difference matter much for desktop applications.)
Since I work normally in R&Ds, my story is slightly different.
1. People often ask questions: per e-mail, per phone or personally coming to my office.
2. I myself also has to ask questions often, what is also distraction. (And in larger companies, with generally disorganized source code structure, you have to ask question more often.)
Delaying e-mail processing is also often doesn't help. Most mails have some sort of dead-line (hours, days) attached to them. Miss dead-line and some stupid error in your area would go into spec, like domino causing even greater damage later.
Worst case is of course if somebody needs my input during conf call. It's kind of when you are not invited to canf call, but your manager warns that if question related to my work would come up, they would call me. It is pretty much impossible to concentrate on any large piece of work, when you know that you might be interrupted any minute. Is such cases, I often find myself doing nothing else but checking e-mail...
Running each instance in a separate process is NOT new technology [...]
True, *nix does that for last 3 decades.
The point here (and of RTFA) is that finally on Windows processes are becoming cheaper, making them usable for all the nasty stuff *nix was indulging itself for all the time.
On NT 3.5, creation of new process was taking sometime as long as 300ms. Imaging Chrome on NT: if you open three tabs and start three new processes, on NT in the times, that alone would have taken about one second.
Unix never had the problem. It's Windows specific. And they are improving.
In corporations, you have to react to e-mail fast. That's why people check it often.
I'd say working in large companies is more dangerous (and distracting) than e-mail itself.
Working for smaller companies, I never had problems writing 1000+ lines of code per day. Working in large companies, I have to stay after 6pm to be able to concentrate at all. And e-mail, believe me, is least of the distractions.
Redhat has a reputation for leading the industry and releasing quality products in the past.
You either: never used RH or used only RH.
RH has two major sicknesses.
1. Pushing untested alpha, unversioned(!) stuff on their customers. glibc and gcc pretty much always bear "CVS112234433435343" monikers instead of real versions. Number of applied patches to some program make most version numbers pretty meaningless.
2. "Not invented here" syndrom. SuSE did something for many years. Debian did something for many years. Users even ported that over to RH. Next version we see that RH finally woke up and ... right: disregarded everything what already there and build something from scratch. See #1 why it never worked and took couple of version for them to stabilize the software. ("2 service packs before deployment" rule from Windows world was and is also applicable to RH.)
Not that I have something against system I have to use occasionally, but pretty much everybody I know who runs RH (be it Fedora or RHEL) runs it for one sole reason: "we have to, our bigger partners are using it." I yet to meet single person who uses OS from RH for some other reasons.
And hey! It worked!! For at least one company: Apple
Though I think Apple's reasons were quite different from being lobbied. Jobs once quoted saying that it's not his work to do products. His work is to keep business out of way of the engineers who do the products.
Apple got many young graduates, many of whom worked before and grew up on Linux and BSD. And of course the people had something for F/LOSS and I personally think that Apple really understood the fact that most software layers in modern computers are pretty much standardized so it make no sense to reinvent the wheel. But what make sense is to try to take advantage of all what was already developed out there. Contributing back is also no-brainer and take little of time, while giving developers (otherwise hidden deep in corporate org-charts) some visible credit.
Case of TiVo is very different from RH's one. And for TiVo, as end user you have alternative to build your own appliance with MythTV. TiVo tries to protect its hardware on one side and follow its contract obligations to content distributors on another.
With RH's governance and support strict guidelines, many users found themselves in situation they were with commercial *nices: do not touch anything, do not change anything, wait for us to do it.
Having source code for RH is already meaningless, because if you would change something, they would (very likely) refuse to support you.
With small/medium business being largest (by user count) user of RH, its focus on Fortune 100 companies, screws royally everybody else. And as small/medium business, you would never ever get the same treatment from RH as its Fortune 100 customers.
Another difference is that nobody forces you to buy TiVo. But many companies literally have to use Fedora/buy RHEL because they have to be compatible with software stack their bigger partners are using. And running the same software is easiest way to accomplish that and only way which guarantees 100% trouble free relationships. That again is major regression from F/LOSS to ways of old proprietary *nices and M$Windows.
From my knowledge of such contracts, you could never really sue software provider. Exceptions are mission critical and life support systems. (By mission critical I mean real mission critical - not "business critical". e.g. avionics.)
From my experience, most problems come from hardware. And biggest problem is always to properly in hardware to handle such errors. And hardware set-up plays tremendous role in such deployments. You have probably 5-10 pieces of software to test and some thousands hardware devices compromising the whole infrastructure. Failure rate of hardware is obviously higher.
Well, seven hours, at least to me, look like Windows Server said it wants to update. After update all other said "bueh!" and demanded to be updated too. MS has a history of updates with requirement of simultaneous update of *all* servers across your network. He-he... 5 nines... Good luck.
SecuROM disallows me to play any game, unless I physically disconnect my Plextor DVD burner... Went through lots of pains when trying to install/play Quake 4.
In business, generally it means that solution provider (software + hardware) bears direct responsibility for all unplanned downtimes.
If solution cannot provide such service availability, the solution provider has to be ready to cover all the damages. And it is often planned that way from day one: some downtimes are covers by the "5 nines", some are covered monetarily by solution providers.
That's why 5 nines solutions cost as much as they cost: on one side to allow providers to bring quality of solution to desired level, on another side, in case of emergency, to let them to cover some downtimes with money.
But covering seven(!) hours(!!) can be lethal to the solution provider. But again, it all depends on their support contract. Some (cheaper) 5 nines are delivered without any guarantees: they only theoretically 5 nines and provide only "best effort" service availability.