By taking out Red Hat MS would not so much create a vacuum in the Linux space as unifying it. Today prof Linux is divided in two camps: Red Hat and Novell/Suse (yes, there is also the roll-it-yourself crowd but they don't buy anything anyway so leave them out of this). This fragmentation helps the opposition (MS).
Taking out Red Hat would unify the market around Novell/Suse. At the end of the day the long term outcome would be the exact opposite of killing Linux. So it's a great way for MS to shoot themselves in the foot. Fire away...
Should I expect less if I make jerky motions into my pockets when a police officer pulls me over for a routine traffic accident?
I find it very disturbing that you consider it natural that a cop kills you if you make any sudden moves. It means that the cop threats the place like a high risk area.
Isn't it a bit sick to call it normal to be living in such a high risk area ?
I mean if someone can write a good Java app to do development, why can't they write a good app to do anything else? Most all of them tend to be bloated, slow, and have an ugly UI.
We're busy with the IDE's at the moment can you call back later... much later ?
What bloat really means is a gigantic lib of great parts so you don't have to code everything from scratch. The core language is still fairly compact. Of course not as compact as C but nothing else is that small. It's the swiss army knife of programming languages.
Now try to compary Java with C++. I mean REALLY C++. All of it. Now that is a big language even without STL.
Java GUI's can be slow. Swing in particular takes a lot of flak and I've seen some nasty personal (and public) attacks on Swing core people. The truth of the matter is that it all depends on how you program stuff. JBuilder's gui is build on swing and the last time I checked it was rather snappy.
Anyway the fun stuff is on the server-side, there Java has really found a home. There is also a lot of development happening in that area and the best of it open-source. Don't burry Java yet.
PostgreSQL is the "secret" oss database and that is a shame. I use it professionally and really love it. But MySQL gets all the ink... Thats life.
MySQL is good for some tasks and terrible for others. PostgreSQL really shines where MySQL sucks and is less impressive in cases where MySQL excels. Figure out what your needs are and chose wisely.
In your case I would have gotten Oracle, DB2 or the hell out of town. If you want to run a big gig like the one you outline then you have to come up with some cash.
Personally I would have tried with PostgreSQL instead but it's still 10 times bigger than what I've tried so far with PG. There are 2T PG bases out there but on that scale I suggest you go pro.
Installing PG from source is not exactly rocket science. But if you need the steps spell'ed out then I can recommend the book "Practical PostgreSQL" (http://www.faqs.org/docs/ppbook/book1.htm/)
It's slightly dated but still work just fine.
Sure you need to vacuum the tables with frequent insert/update/deletes but thats the price of REAL ACID. It's not like cron jobs are that hard to setup anyway.
Parent is extremely clued in, but there is a few issues that you may have to consider:
A lot of other posters have (as always and rightfully so) pointed out that you need to provide exact hardware interface spec's and answer questions in a timely and acurate fasion (and stick them in the spec pretty quickly). A beta implementation to work from is also likely to help in getting f/oss support. Check the guidelinece for staring a f/oss project, it's somewhere out there)
The downside to this is that you can NOT design your product in such a way that any of your core business IP is in the driver layer. Some graphics cards vendors have a problem with this and use binary workarounds. Think hard about this, open-source is not a free ride. You may have to move some logic into the firmware in order to provide an open interface.
As in any trade, both parties have to benefit. It's pretty easy to see what f/oss have to deliver you "just" have to play acording to the rules in this particular game. As always it pays to check out the rules in advance...
Plus remember it's a hit'n miss game. People might go crazy about your hardware or completely ignore it. Do some internal marketing, targeted at the potential developers/supporters/migrators to help your odds but don't count on anything. On the other hand it is quite remarkeable what a handfull of dedicated individual can (and regulary) do.
My personal favorite idea for all these electric cars is (in the long run) to have an all electric drive system with an electric engine in each wheel.
NOOO. A bit of nitpicking but in order to have a comfortable ride you NEED to keep the unsprung mass as low as you can (alu wheels anyone ?). Sticking an elecric motor (know for high weight/power ration) in the wheels is a poor idea from this point of view.
I looked into the issue a few years back and in my country (at the time) the energy loss from the electrical distribution grad was around 1-2%. Eliminating that loss is a noble idea but it won't change much.
Now the part about not driving around like crazy makes a lot more sense.
The other extremely important factor is the "Warm and fuzzy feeling(tm)" in your manager. It boils down to covering his ass. Having a really big name behind your distro really helps. Novell/Suse have a winning hand here. We all know that in the real world vendors won't cover jack-shit but it's all part of the big lie. Various bogus partner programs can also help here but not as much.
The more insecure your maneger is the more important these factors are.
But having your key applications certified on your distro of choice is essential unless you've got source for them and can roll them yourself.
The only thing that QoS can help with is prioritization inside the gateway (so that little Joe's mp3 download doesn't interrupt Little Jane's VoIP call).
I do this sort of thing for our enterprise customers that have lots of locations all connected through our backbone. In order to run telephony through that system system without complaints QoS is no laughing matter. Joe and Jane tend to be CTO and CEO they have very little sense of humour.
And no QoS is not limited by gateways you just (easy to say) have to handle it on layer 3 also.
As to private customers. Show me the money an I'll give a fuck...
It is all in the codec (and configuration thereof) that your provider uses.
Are you for real ?
The codec determines the bandwith/voice quality tradeoff that's true but thats less than half the issue. The real deal is quality-of-service (QoS) in layer 2 (ethernet/atm etc) and layer 3 (IP). When you have QoS in hand and a reasonable bandwith ALL-THE-WAY through then you've got a real VoIP system.
I happen to do this stuff for a living and QoS is rather hard. In particular when you don't have much control over your customers (crappy) networks.
I counter: Follow the Unix Way: Each program does one thing: What you need is another program.
Correct if it needs to do something completely different. But that question is trivial to answer. None of us would mod a sportsbike to double as a tow truck.
The question really is: The program needs to do something slightly different (the business has changed) or a little bit more (business scope has grown).
The lesson trivialises a complex issues. Code needs to change. Acording to Brooks 80% of the cost of code lies in this area.
Write a nice long java doc on top that describes the class/method whatever. What goes in, what goues out etc. from an outside poiunt of view.
Notes on inside details are optional. I find that if you need to comment the details inside your methods then your code is simply not good enough. Use discriptive class/method/member names, polish the algorithm until it obvious. If it still looks like shit then you need to expand your scope and refactor some of the related classes. I consider comments inside methods to be admitting failure. There are times where you end up with code that's deep magic and you have to comment but this should be the exeption not the rule.
Aside from that I like to have some sort of map of the whole project in order to see the big picture. Autogenerated UML plus some highlevel design considerations (can be captured in a wiki) works for me.
The cost of the suit is far sufficient to do this guy in.
He's a student for christ-sake fine him $1000 and he's done for. With a bit of luck on their part they'll ruin any chance he has at med-school. Sure he's an ass-hat but the media fall-out for Apple could easily offset any anti-piracy gains.
Think twice before you run the steamroller over this guy.
Why all this tracking ? Put tax on gas instead. That way gas guzzlers are harder hit than less poluting cars. Its a lot simpler and its a lot harder to track people that way.
I wonder if we can get her a job at Oracle, or Sun, or even Microsoft?
As far as I remember there is something in the law about cruel and unusual punishment. At least two of the companies you mention deserves the very worst but there are limits...
Assuming euro-style charging (ie. caller pays) things can get really interesting with regard to charging of ported numbers.
One issue is porting between mobiles and fixed phones. The other is geographic portability.
The end result is that you can get royally screwed if you call a number that looks like a local fixed phone but really is a mobile i Timbuktu and cost you a buck/sec.
When you throwing VoIP into the mix then you regulary end up using an operator from out-of-state and an out-of-state number. Particulary if you move around. That can get funny real quick.
Taking out Red Hat would unify the market around Novell/Suse. At the end of the day the long term outcome would be the exact opposite of killing Linux. So it's a great way for MS to shoot themselves in the foot. Fire away ...
http://www.theserverside.com/cartoons/TalesFromThe ServerSide.tss
Scroll down to the cartoon named "The Conspiracy". It's on the right side of the page.
I find it very disturbing that you consider it natural that a cop kills you if you make any sudden moves. It means that the cop threats the place like a high risk area.
Isn't it a bit sick to call it normal to be living in such a high risk area ?
We're busy with the IDE's at the moment can you call back later ... much later ?
Now try to compary Java with C++. I mean REALLY C++. All of it. Now that is a big language even without STL.
Java GUI's can be slow. Swing in particular takes a lot of flak and I've seen some nasty personal (and public) attacks on Swing core people. The truth of the matter is that it all depends on how you program stuff. JBuilder's gui is build on swing and the last time I checked it was rather snappy.
Anyway the fun stuff is on the server-side, there Java has really found a home. There is also a lot of development happening in that area and the best of it open-source. Don't burry Java yet.
MySQL is good for some tasks and terrible for others. PostgreSQL really shines where MySQL sucks and is less impressive in cases where MySQL excels. Figure out what your needs are and chose wisely.
Personally I would have tried with PostgreSQL instead but it's still 10 times bigger than what I've tried so far with PG. There are 2T PG bases out there but on that scale I suggest you go pro.
Sure you need to vacuum the tables with frequent insert/update/deletes but thats the price of REAL ACID. It's not like cron jobs are that hard to setup anyway.
A lot of other posters have (as always and rightfully so) pointed out that you need to provide exact hardware interface spec's and answer questions in a timely and acurate fasion (and stick them in the spec pretty quickly). A beta implementation to work from is also likely to help in getting f/oss support. Check the guidelinece for staring a f/oss project, it's somewhere out there)
The downside to this is that you can NOT design your product in such a way that any of your core business IP is in the driver layer. Some graphics cards vendors have a problem with this and use binary workarounds. Think hard about this, open-source is not a free ride. You may have to move some logic into the firmware in order to provide an open interface.
As in any trade, both parties have to benefit. It's pretty easy to see what f/oss have to deliver you "just" have to play acording to the rules in this particular game. As always it pays to check out the rules in advance...
Plus remember it's a hit'n miss game. People might go crazy about your hardware or completely ignore it. Do some internal marketing, targeted at the potential developers/supporters/migrators to help your odds but don't count on anything. On the other hand it is quite remarkeable what a handfull of dedicated individual can (and regulary) do.
NOOO. A bit of nitpicking but in order to have a comfortable ride you NEED to keep the unsprung mass as low as you can (alu wheels anyone ?). Sticking an elecric motor (know for high weight/power ration) in the wheels is a poor idea from this point of view.
Now the part about not driving around like crazy makes a lot more sense.
The other extremely important factor is the "Warm and fuzzy feeling(tm)" in your manager. It boils down to covering his ass. Having a really big name behind your distro really helps. Novell/Suse have a winning hand here. We all know that in the real world vendors won't cover jack-shit but it's all part of the big lie. Various bogus partner programs can also help here but not as much.
The more insecure your maneger is the more important these factors are.
But having your key applications certified on your distro of choice is essential unless you've got source for them and can roll them yourself.
I do this sort of thing for our enterprise customers that have lots of locations all connected through our backbone. In order to run telephony through that system system without complaints QoS is no laughing matter. Joe and Jane tend to be CTO and CEO they have very little sense of humour.
And no QoS is not limited by gateways you just (easy to say) have to handle it on layer 3 also.
As to private customers. Show me the money an I'll give a fuck...
Are you for real ?
The codec determines the bandwith/voice quality tradeoff that's true but thats less than half the issue. The real deal is quality-of-service (QoS) in layer 2 (ethernet/atm etc) and layer 3 (IP). When you have QoS in hand and a reasonable bandwith ALL-THE-WAY through then you've got a real VoIP system.
I happen to do this stuff for a living and QoS is rather hard. In particular when you don't have much control over your customers (crappy) networks.
Correct if it needs to do something completely different. But that question is trivial to answer. None of us would mod a sportsbike to double as a tow truck.
The question really is: The program needs to do something slightly different (the business has changed) or a little bit more (business scope has grown).
The lesson trivialises a complex issues. Code needs to change. Acording to Brooks 80% of the cost of code lies in this area.
Parrent should be modded funny and/or redundant.
Write a nice long java doc on top that describes the class/method whatever. What goes in, what goues out etc. from an outside poiunt of view.
Notes on inside details are optional. I find that if you need to comment the details inside your methods then your code is simply not good enough. Use discriptive class/method/member names, polish the algorithm until it obvious. If it still looks like shit then you need to expand your scope and refactor some of the related classes. I consider comments inside methods to be admitting failure. There are times where you end up with code that's deep magic and you have to comment but this should be the exeption not the rule.
Aside from that I like to have some sort of map of the whole project in order to see the big picture. Autogenerated UML plus some highlevel design considerations (can be captured in a wiki) works for me.
Feed it this link: http://play.rbn.com/?url=usanet/usanet/g2demand/sc ifi/battlestar/33/33.rm&proto=rtsp
And your in business. Same way i grabbed h2g2 part 3.
http://www.eclipse.org/
Can't we have some more hints on whats in between the two ?
He's a student for christ-sake fine him $1000 and he's done for. With a bit of luck on their part they'll ruin any chance he has at med-school. Sure he's an ass-hat but the media fall-out for Apple could easily offset any anti-piracy gains.
Think twice before you run the steamroller over this guy.
Why all this tracking ? Put tax on gas instead. That way gas guzzlers are harder hit than less poluting cars. Its a lot simpler and its a lot harder to track people that way.
As far as I remember there is something in the law about cruel and unusual punishment. At least two of the companies you mention deserves the very worst but there are limits ...
Exept from the minor fact that China also lends you the money to buy the goods.
The end result is that you can get royally screwed if you call a number that looks like a local fixed phone but really is a mobile i Timbuktu and cost you a buck/sec.
When you throwing VoIP into the mix then you regulary end up using an operator from out-of-state and an out-of-state number. Particulary if you move around. That can get funny real quick.
Their resources would be better spent on improving an existing open-source db. My personal favorit is Postgresql but hey, it's their money.