...I'm having a hard time getting over a one year warranty on IDE drives. I'll start to believe that people care about hardware lifespan when SCSI drives with a five year warranty start to become the norm again.
...and you can ignore it whenever the code profiler shows you that you don't need to care about it, and you can switch allocaters extremely late on in the development process.
Which is only true when you're dealing with badly written manual memory management. C++ custom allocators avoid that problem, and let the programmer specify the best behaviour for every given situation.
The C++ model is basically correct. It doesn't treat the programmer like an idiot (which admittedly may be a problem if you have idiot programmers), and it gives you the choice of how to handle memory allocation. The lack of reference-counted pointer in the standard library is a bit of a bitch, but the Boost shared pointer templates will likely make it into C++0x, and it's only a hundred lines of code or so to make your own in the mean time.
Of course, the C++ model is not perfect either. Lack of virtual and const constructors can be a nuisance (the workaround being the pimpl idiom and a shared pointer), and not being able to use shared pointers to functions without nasty syntactic hackery occasionally breaks the "stuff pretending to be a pointer" illusion. Still, the power it gives over the Java model is definitely worth the occasional bit of extra effort.
Then again, if you're coding some quick scripting hack rather than a proper program, who cares about memory allocation?
...is some honest benchmarks of Oracle against Postgres. That would be far more interesting. Does anyone happen to have a copy of Oracle that isn't covered by obnoxious "no benchmarking" licence clauses?
It can't be done with dynamic linking, despite what the Autopackage people tell you. There's too much variety between distributions with things like libc and libstdc++ versions. There's even too much variety between distribution releases in many cases.
Most distributions don't aim to provide binary compatibility between releases. Even RedHat get sick of shipping multiple copies of libraries eventually... And if you throw distributions like Gentoo into the mix, anything binary-based using dynamic linking is out of the question.
If you really must distribute binaries, static link them and distribute the associated libraries too. Assuming, of course, that said libraries' licences don't prohibit this -- for open things you're fine, but for obnoxiously licenced code (like your own) you're short of luck. Also note that you can't legally do this with LGPLed libraries (nor GPLed, of course).
*shrug* Of course, any respectable Linux user won't use your software unless they can see the code anyway. How else do we know it's not chock full of security holes and spyware?
I'd just like to say thanks for trying to waste my hard-earned tax money on this, rather than going out and using it for something useful like fixing the sorry state of our education system or making the NHS ever so slightly less pathetic.
OpenSolaris is an occasionally amusing diversion, like Hurd or Darwin. Sure, it has a small band of fanatics who're pushing it like crazy, but it'll never reach the serious computing crowd.
Eh? Java is 'cross platform' only in that it forces you to use the lowest common subset of all 'supported platforms'. Plus, far fewer platforms have a working JRE than a working C or C++ compiler or Perl or Ruby interpreter.
Sure. Because Complex x = (a + b) * c; is so much less readable than Complex x = (a.add(b)).assign(c); .
Java disallowing C++-style constants, operator overloading, templates and everything else useful just adds to the theory that Java is C++ for stupid people.
./configure --with-features=minimal --with-gui=none --disable-x11 && make && sudo make install
Or, in Gentoo, USE="minimal" emerge vim
All of Vim's features are optional. You can even do silly things like turning off support for everything except vt100 if you really want...
Re:Bugggg fix only. nice
on
Vim 6.4 Released
·
· Score: 5, Informative
No no no. The features are being added in the 7.x branch, which you can get from CVS. 6.x is purely for maintenance (ie bugfixes). This is a mixed blessing... It means 6.x is extremely stable, but if you want new goodies like spellchecking and intelligent autocompletion, you have to switch to the CVS only branch.
It's a tricky decision. Some projects are way over on the side of "keep throwing out new versions with new features and new bugs". Vim is way over on the other extreme: "release 'new feature' releases every few years and keep the stable branch working". For end users it's a mixed blessing.
Fortunately, the 7.x branch is pretty much stable (as in every day usable) at the moment. I've been using the Gentoo ebuilds (package.masked), which means I get a CVS snapshot which has been at least reasonably well checked and had any icky bugs fixed. I'd hate to miss out on the new toys. The 'numberwidth feature alone makes it worth the upgrade, even if 'spell didn't exist.
Then you might want to look at vim 7, which is where all the features are going. Spell checking, intelligent autocompletion, a hell of a lot of new tweaks that make vim even nicer to work with.
The 6.x branch is in 'maintenance mode', meaning it's bugfixes only. The 7.x branch is where all the work's going on, and vim 6 to vim 7 is already like going from vi to vim.
I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespacethank you very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. It's like Ada all over again! The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.
So now as well as having to buy faster graphics cards, we'll have to buy faster CPUs to cope with Python's "Oh shit, you seriously want me to call a function? Woah. Hang on a minute..." feature? I'm all for open source, but Python's fucked up hash tables implementation is a perfect example of how more eyes won't get around to fixing things if they're not looking in the right places...
Unfortunately, Sun are far too expensive for the low end market and for high end kit they can't come close to competing with IBM. Their low end kit is twice the price and half the quality of any other big manufacturer, and their insistence that Linux sucks doesn't help either...
Learn the difference between "its" and "it's". Given the huge amount of choice available, your typical discerning geek will likely start by ignoring any company whose employees are not smart enough to master basic English. Proper grammar doesn't imply a good company, but bad grammar does suggest a general level of shoddiness.
The ti86 has an interrupt which is called ~186 times per second. By toggling the graphics viewport every two then one cycles, you could get a very realistic-looking four level greyscale setup. Do the newer models no longer have such a feature? Or is this down to slower CPUs?
Not true. You can get any digit in base 16 of pi without needing to know any other digit. This means you can get groups of digits in any base by only calculating a relatively small (maximum 16 * base) number of other digits in base 16 and converting.
Hopefully now more effort will be made towards core functionality and better drivers rather than wasting time on annoying eye candy CPU drain. Mod me troll if you will, but I for one would rather have time devoted to proper usable drivers for modern graphics cards than some silly extras that eat all my CPU and RAM but contribute nothing towards functionality or productivity.
Slashdot Mirror
...I'm having a hard time getting over a one year warranty on IDE drives. I'll start to believe that people care about hardware lifespan when SCSI drives with a five year warranty start to become the norm again.
...and you can ignore it whenever the code profiler shows you that you don't need to care about it, and you can switch allocaters extremely late on in the development process.
Which is only true when you're dealing with badly written manual memory management. C++ custom allocators avoid that problem, and let the programmer specify the best behaviour for every given situation.
The C++ model is basically correct. It doesn't treat the programmer like an idiot (which admittedly may be a problem if you have idiot programmers), and it gives you the choice of how to handle memory allocation. The lack of reference-counted pointer in the standard library is a bit of a bitch, but the Boost shared pointer templates will likely make it into C++0x, and it's only a hundred lines of code or so to make your own in the mean time.
Of course, the C++ model is not perfect either. Lack of virtual and const constructors can be a nuisance (the workaround being the pimpl idiom and a shared pointer), and not being able to use shared pointers to functions without nasty syntactic hackery occasionally breaks the "stuff pretending to be a pointer" illusion. Still, the power it gives over the Java model is definitely worth the occasional bit of extra effort.
Then again, if you're coding some quick scripting hack rather than a proper program, who cares about memory allocation?
...is some honest benchmarks of Oracle against Postgres. That would be far more interesting. Does anyone happen to have a copy of Oracle that isn't covered by obnoxious "no benchmarking" licence clauses?
It can't be done with dynamic linking, despite what the Autopackage people tell you. There's too much variety between distributions with things like libc and libstdc++ versions. There's even too much variety between distribution releases in many cases.
Most distributions don't aim to provide binary compatibility between releases. Even RedHat get sick of shipping multiple copies of libraries eventually... And if you throw distributions like Gentoo into the mix, anything binary-based using dynamic linking is out of the question.
If you really must distribute binaries, static link them and distribute the associated libraries too. Assuming, of course, that said libraries' licences don't prohibit this -- for open things you're fine, but for obnoxiously licenced code (like your own) you're short of luck. Also note that you can't legally do this with LGPLed libraries (nor GPLed, of course).
*shrug* Of course, any respectable Linux user won't use your software unless they can see the code anyway. How else do we know it's not chock full of security holes and spyware?
...next to "Building Castles on Sand".
I'd just like to say thanks for trying to waste my hard-earned tax money on this, rather than going out and using it for something useful like fixing the sorry state of our education system or making the NHS ever so slightly less pathetic.
OpenSolaris is an occasionally amusing diversion, like Hurd or Darwin. Sure, it has a small band of fanatics who're pushing it like crazy, but it'll never reach the serious computing crowd.
Eh? Java is 'cross platform' only in that it forces you to use the lowest common subset of all 'supported platforms'. Plus, far fewer platforms have a working JRE than a working C or C++ compiler or Perl or Ruby interpreter.
Sure. Because Complex x = (a + b) * c; is so much less readable than Complex x = (a.add(b)).assign(c); .
Java disallowing C++-style constants, operator overloading, templates and everything else useful just adds to the theory that Java is C++ for stupid people.
I'm surprised no-one has replied to your comment yet, so I'll explain. It stands for "read the fucking privacy policy".
./configure --with-features=minimal --with-gui=none --disable-x11 && make && sudo make install
Or, in Gentoo, USE="minimal" emerge vim
All of Vim's features are optional. You can even do silly things like turning off support for everything except vt100 if you really want...
No no no. The features are being added in the 7.x branch, which you can get from CVS. 6.x is purely for maintenance (ie bugfixes). This is a mixed blessing... It means 6.x is extremely stable, but if you want new goodies like spellchecking and intelligent autocompletion, you have to switch to the CVS only branch.
It's a tricky decision. Some projects are way over on the side of "keep throwing out new versions with new features and new bugs". Vim is way over on the other extreme: "release 'new feature' releases every few years and keep the stable branch working". For end users it's a mixed blessing.
Fortunately, the 7.x branch is pretty much stable (as in every day usable) at the moment. I've been using the Gentoo ebuilds (package.masked), which means I get a CVS snapshot which has been at least reasonably well checked and had any icky bugs fixed. I'd hate to miss out on the new toys. The 'numberwidth feature alone makes it worth the upgrade, even if 'spell didn't exist.
Then you might want to look at vim 7, which is where all the features are going. Spell checking, intelligent autocompletion, a hell of a lot of new tweaks that make vim even nicer to work with.
The 6.x branch is in 'maintenance mode', meaning it's bugfixes only. The 7.x branch is where all the work's going on, and vim 6 to vim 7 is already like going from vi to vim.
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespacethank you very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. It's like Ada all over again! The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.
What makes you think Diebold can make secure ATMs?
Uncyclopedia's been around since the start of the year. In Internet terms, this does not exactly make it new...
So now as well as having to buy faster graphics cards, we'll have to buy faster CPUs to cope with Python's "Oh shit, you seriously want me to call a function? Woah. Hang on a minute..." feature? I'm all for open source, but Python's fucked up hash tables implementation is a perfect example of how more eyes won't get around to fixing things if they're not looking in the right places...
Unfortunately, Sun are far too expensive for the low end market and for high end kit they can't come close to competing with IBM. Their low end kit is twice the price and half the quality of any other big manufacturer, and their insistence that Linux sucks doesn't help either...
Also, RMS got a boob job and Ben Collins had his hair cut. Front page news at 11.
Is slashdot a celebrity gossip site for geeks now or something?
Learn the difference between "its" and "it's". Given the huge amount of choice available, your typical discerning geek will likely start by ignoring any company whose employees are not smart enough to master basic English. Proper grammar doesn't imply a good company, but bad grammar does suggest a general level of shoddiness.
The ti86 has an interrupt which is called ~186 times per second. By toggling the graphics viewport every two then one cycles, you could get a very realistic-looking four level greyscale setup. Do the newer models no longer have such a feature? Or is this down to slower CPUs?
Not true. You can get any digit in base 16 of pi without needing to know any other digit. This means you can get groups of digits in any base by only calculating a relatively small (maximum 16 * base) number of other digits in base 16 and converting.
Hopefully now more effort will be made towards core functionality and better drivers rather than wasting time on annoying eye candy CPU drain. Mod me troll if you will, but I for one would rather have time devoted to proper usable drivers for modern graphics cards than some silly extras that eat all my CPU and RAM but contribute nothing towards functionality or productivity.