I've been using FreeBSD as a desktop for at least 10 years now. You pretty much have everything a Linux box has, KDE, Gnome, XFCE, Openbox, Windowmaker, whatever you want.
What is the state of hardware accelerated video playback? Last time I was looking into it, it wasn't even experimental yet.
And more importantly...
on
Vim Turns 20
·
· Score: 1
Sure, that could've been one of the reasons _in the past_. It's no longer a reason now. All things equal, FLAC is less CPU demanding than ALAC, for both encoding and decoding.
But people who can't see an obvious marketing tactic by Apple are blind.
Oh STFU.
Unlike MSFT, Apple actually supports pretty much indefinitely all the audio and video formats once included in all previous version of Mac OS. ALAC is on the list too.
There is precisely 0 marketing in the source code release. Some software engineers probably finally got permission to make the code open source. That's about all what is there in the story.
Making ALAC open source is just a strategy to get more manufacturers on board, so that iTunes ALAC purchases will work on non-Apple devices.
ALAC is supported by Cowon audio players since 2009, if I'm not mistaken. RockBox supports it too.
Nobody actually cares that much about what lossless wrapper the music has, since duh the formats are lossless and music can be converted from one to another without any loss.
Built-in message passing? Multi-threading without shared resources? Weak typing?
I know no other imperative language that offer that combination. Optional libraries - yes. But not at the core of the language. And optional libraries are pain to handle in the long term.
In the end, it boils down mostly to the simple fact: Dart is supported by Google AND Google has sufficient resources to kick start widespread adoption of the new language.
. net sucks. Perl, Pascal, all interpreted languages are a dead end. They're ui elements that don't count. If you can't use your available source to build theOS
the compiler and core apps, you lose.
An example of an OS or a libc (or analogous system library) written without assembler in studio please!
Not really. For once I did not have to share any personal information with the people who "followed" me - or Google itself for the matter.
To me, Google Reader's Shared Items was the perfect "social network." This was as much of a "social" interaction as I need: stories and news few close to me people are interested in, probably with their comments. Not between me, my friends, Google and whole shebang of random strangers - but just between me and my friends.
Then go buy the hardcover version, and leave the free market to correct itself.
Guess who's collecting royalties on the hardcover version?
As I see it, the cabal of publishers is precisely why Amazon is doing what it is doing.
In the end, I'm not really sure that the publisher's iron grip on authors is much worse than the Amazon DRM-y iron grip on consumers. Both are bad, though the latter doesn't involve dead trees.
Opposed-piston engines (with two pistons in the same cylinder)
Are those the same as so called boxer engines? which are found in Porsches and BMW motorcycles? What's the difference if any?
Re:haskell for the masses? sure, but only...
on
OCaml For the Masses
·
· Score: 1
"My recollection of functional programming from university was that it was kind cute, seemed to be geared to solving a problem domain I never found a use for, but that ultimately I hated the syntax and structure of it. I never really "got it", or really understood what it was supposed to be useful for."
Holy shit - you just described my experience with functional languages *exactly*. GET OUT OF MY HEAD!
I can't believe it... I'm not alone!!
My cure was this. The 3rd chapter in particular. After reading few chapters I have finally realized that there was, after all, a programming language invented which is much more powerful than the assembler. Not that I need it - but definitely cleared my head off the overdoze of Haskell learning material which failed even to explain how to write/compile a program in it.
Re:haskell for the masses? sure, but only...
on
OCaml For the Masses
·
· Score: 1
If only Haskell had some decent tutorials.
I have read a couple, and while reading the second one, I have seen something interesting and I wanted to code it and see how it runs. It was only then I realized that I have read 1.5 Haskell tutorials and I yet can't write/run even Hello World in it. Because none of them even bothered to define what the hell a Haskell program is.
Haskell might be nice, but judging a language by type of articles about it, both Lisp and Erlang are light years ahead. They explain how to solve problems at hand - and waste much much less pages signing odes how beautiful and concise the syntax is.
Returning to Haskell. I haven't found a single decent explanation of what the hell monad is. Most concise to date is "a monad is a monoid in the category of endofunctors". But neither that has advanced my understanding of Haskell or monads any further.
Inapplicable. Criminals commonly lose some of their human rights, while making up for their crimes.
Another question is whether the government does really want to turn a sizable chunk of the populace into criminals. After all, if a person crossed the line once, crossing it again becomes much less of a moral issue.
My home PC runs without Java for 5 or 6 years now. On office PC, Java in browser is disabled.
The biggest problem I have encountered in all the years are the error messages with freshly installed OO.o/LibreOffice starts. (But I heard LO is fixing that.)
These days a whitebox with a SuperMicro board is a lot cheaper with more features at the high end. At the low end I don't know why you would bother looking at HP.
HP stopped moving but the rest of the world didn't.
You missed the bit about "decent support contract." We need our suppliers to be able to provide customers with systems which they can support for 5-10 years. Except for the HP, IBM and Sun/Oracle very few companies are doing it.
And reading through it, as couple of years ago, I do not see any way to disable the awesomeness bit they have added.
I do not mind it at home, but I can hear my office laptop's HDD cringe and Fx freeze every time I try to type/search something via URL bar.
The problem is not the "awesomeness bit" itself - the suckage is inside the SQLite used in the background, degrading performance by hitting HDD way too often and with high latencies. As if it can't cache the few MBs of the history/bookmarks in the RAM... Just like all browsers did it before and all sensible browsers go on doing it right now. But Mozilla IIRC is dead set on using the SQLite... Well, I'm on 3.6 - time will tell what my next browser would be. Not FireFox, that's much I'm sure of.
The former is mostly about wiring a CPU. And instruction set.
The latter is about: memory and memory controllers, IO controller, interrupt controllers, external RTCs, and the rest of carp you usually find soldered on a motherboard. All the carp for which the OS requires a proper driver.
While CPU spec might be free, the rest of the controllers, which are required to bring up the system, are mostly proprietary H/W.
Good luck with the ProLiants. They ain't what they used to be, according to a friend recently ex- of HP.
They are just generic x64 servers, with a decent support contract from HP. I doubt they are worse or better than the cheap generic Intel boxes from any other manufacturer.
I was under impression that HP offered us a sweet deal on x64 servers (ProLiants) our management couldn't refuse. And why on earth run a Linux on proprietary hardware?
Old SPARCs would remain of course, but only for purposes of support and maintenance of old versions of our software.
We have bunch of old T2 - and they... suck. Even on highly multithreaded Java workloads.
Is there a way for a CPU to make mutex handling easier and more efficient?
No. It is inherently expensive operation because the updates to critical section must be propagated between all the CPUs/cores (and their caches). CPU ops for mutex itself are puny, compared to the (invisible) mechanics beneath which guarantees the cache coherency. (More CPUs/cores you have - higher the potential overhead.)
Another thing which might be worth looking into speeding up is "gettimeofday" and "trigger on event or register/memory=certain value" - I bet there's lots of code which regularly checks "is it time to do X yet?" or "wait till X happens" (e.g. wait for connection or data).
`gettimeofday` is already optimized and not a real syscall on Linux and Solaris.
Maybe these aren't that CPU intensive so speeding them up won't help much in performance?
They are CPU intensive - but negligible - because they were already heavily optimized.
Overall, GP's suggestion that DB take lots of locks is sort of right - but misses the fact that there are many many locks so collisions are relatively rare. Those are most of the time logical data locks, not real mutexes. And collision are most of the time also of the logical nature: one user tries to update data which are currently being updated by another; one use tried to read data which were updated but not committed by the other; and so on.
DB are generally IO bound: they must provide guarantee that committed data were safely written to disk. This is where the most of DB's performance is wasted - waiting for the disk to do its job.
Or more to the point: why organizations are picking RISCs at all?
Either Intel or author of RTFA is missing the point. Most organizations use RISC based systems which come as part of the business critical solutions. Hardware rarely accounts for 10% of the deal. Software licenses, deployment, testing and long term support are where the real money are.
Unless Intel introduces an architecture which it commits to support for at least one decade, I do not see a thing changing on corporate landscape. The problem with Intel boxes is that by the time you need a replacement part, the CPU/etc generation have already changed and one needs to replace the whole box. That obviously leads to the problem that you can't install the same tested old version of the OS and of the 3rd party crap - meaning that the whole solution has to be tested from ground up. It is not uncommon for such complete tests be worth more than 1000 person/days. Suddenly, replacement of a single $4000 server becomes a magnitudes more expensive affair.
P.S. But needless to mention that at least some part of the RISC stronghold was already dismantled: DB hosting for which now more and more Linux/x64 is used.
IANAL, but I have impression that you mixed up "copyright" and "authorship." Authorship is not transferable (except for plagiarism, obviously) - copyright is. And, as I understand it, always was: it isn't the author who is making copies of work, but a third party, e.g. publisher.
Slashdot Mirror
I've been using FreeBSD as a desktop for at least 10 years now. You pretty much have everything a Linux box has, KDE, Gnome, XFCE, Openbox, Windowmaker, whatever you want.
What is the state of hardware accelerated video playback? Last time I was looking into it, it wasn't even experimental yet.
C-x C-c
Sure, that could've been one of the reasons _in the past_. It's no longer a reason now. All things equal, FLAC is less CPU demanding than ALAC, for both encoding and decoding.
But people who can't see an obvious marketing tactic by Apple are blind.
Oh STFU.
Unlike MSFT, Apple actually supports pretty much indefinitely all the audio and video formats once included in all previous version of Mac OS. ALAC is on the list too.
There is precisely 0 marketing in the source code release. Some software engineers probably finally got permission to make the code open source. That's about all what is there in the story.
Making ALAC open source is just a strategy to get more manufacturers on board, so that iTunes ALAC purchases will work on non-Apple devices.
ALAC is supported by Cowon audio players since 2009, if I'm not mistaken. RockBox supports it too.
Nobody actually cares that much about what lossless wrapper the music has, since duh the formats are lossless and music can be converted from one to another without any loss.
Built-in message passing? Multi-threading without shared resources? Weak typing?
I know no other imperative language that offer that combination. Optional libraries - yes. But not at the core of the language. And optional libraries are pain to handle in the long term.
In the end, it boils down mostly to the simple fact: Dart is supported by Google AND Google has sufficient resources to kick start widespread adoption of the new language.
. net sucks. Perl, Pascal, all interpreted languages are a dead end. They're ui elements that don't count. If you can't use your available source to build theOS the compiler and core apps, you lose.
An example of an OS or a libc (or analogous system library) written without assembler in studio please!
Not really. For once I did not have to share any personal information with the people who "followed" me - or Google itself for the matter.
To me, Google Reader's Shared Items was the perfect "social network." This was as much of a "social" interaction as I need: stories and news few close to me people are interested in, probably with their comments. Not between me, my friends, Google and whole shebang of random strangers - but just between me and my friends.
Then go buy the hardcover version, and leave the free market to correct itself.
Guess who's collecting royalties on the hardcover version?
As I see it, the cabal of publishers is precisely why Amazon is doing what it is doing.
In the end, I'm not really sure that the publisher's iron grip on authors is much worse than the Amazon DRM-y iron grip on consumers. Both are bad, though the latter doesn't involve dead trees.
Opposed-piston engines (with two pistons in the same cylinder)
Are those the same as so called boxer engines? which are found in Porsches and BMW motorcycles? What's the difference if any?
"My recollection of functional programming from university was that it was kind cute, seemed to be geared to solving a problem domain I never found a use for, but that ultimately I hated the syntax and structure of it. I never really "got it", or really understood what it was supposed to be useful for."
Holy shit - you just described my experience with functional languages *exactly*. GET OUT OF MY HEAD!
I can't believe it... I'm not alone!!
My cure was this. The 3rd chapter in particular. After reading few chapters I have finally realized that there was, after all, a programming language invented which is much more powerful than the assembler. Not that I need it - but definitely cleared my head off the overdoze of Haskell learning material which failed even to explain how to write/compile a program in it.
If only Haskell had some decent tutorials.
I have read a couple, and while reading the second one, I have seen something interesting and I wanted to code it and see how it runs. It was only then I realized that I have read 1.5 Haskell tutorials and I yet can't write/run even Hello World in it. Because none of them even bothered to define what the hell a Haskell program is.
Haskell might be nice, but judging a language by type of articles about it, both Lisp and Erlang are light years ahead. They explain how to solve problems at hand - and waste much much less pages signing odes how beautiful and concise the syntax is.
Returning to Haskell. I haven't found a single decent explanation of what the hell monad is. Most concise to date is "a monad is a monoid in the category of endofunctors". But neither that has advanced my understanding of Haskell or monads any further.
Inapplicable. Criminals commonly lose some of their human rights, while making up for their crimes.
Another question is whether the government does really want to turn a sizable chunk of the populace into criminals. After all, if a person crossed the line once, crossing it again becomes much less of a moral issue.
I try to avoid any Chinese products because if they'll poison their own children with melamine what would they be willing to do to us.
But you probably allow them to eat at the fast foods. Very wise. [/sarcasm]
P.S. The melamine story ended in 2008.
Is it going to break after 2 or 3 uses like every piece of junk made in China?
Unlikely. That type of junk is reserved for import into US and EU. Chinese keep the good stuff for themselves.
My home PC runs without Java for 5 or 6 years now. On office PC, Java in browser is disabled.
The biggest problem I have encountered in all the years are the error messages with freshly installed OO.o/LibreOffice starts. (But I heard LO is fixing that.)
These days a whitebox with a SuperMicro board is a lot cheaper with more features at the high end. At the low end I don't know why you would bother looking at HP.
HP stopped moving but the rest of the world didn't.
You missed the bit about "decent support contract." We need our suppliers to be able to provide customers with systems which they can support for 5-10 years. Except for the HP, IBM and Sun/Oracle very few companies are doing it.
That's not it.
And reading through it, as couple of years ago, I do not see any way to disable the awesomeness bit they have added.
I do not mind it at home, but I can hear my office laptop's HDD cringe and Fx freeze every time I try to type/search something via URL bar.
The problem is not the "awesomeness bit" itself - the suckage is inside the SQLite used in the background, degrading performance by hitting HDD way too often and with high latencies. As if it can't cache the few MBs of the history/bookmarks in the RAM... Just like all browsers did it before and all sensible browsers go on doing it right now. But Mozilla IIRC is dead set on using the SQLite... Well, I'm on 3.6 - time will tell what my next browser would be. Not FireFox, that's much I'm sure of.
Doesn't work.
CPU specification != system architecture.
The former is mostly about wiring a CPU. And instruction set.
The latter is about: memory and memory controllers, IO controller, interrupt controllers, external RTCs, and the rest of carp you usually find soldered on a motherboard. All the carp for which the OS requires a proper driver.
While CPU spec might be free, the rest of the controllers, which are required to bring up the system, are mostly proprietary H/W.
Good luck with the ProLiants. They ain't what they used to be, according to a friend recently ex- of HP.
They are just generic x64 servers, with a decent support contract from HP. I doubt they are worse or better than the cheap generic Intel boxes from any other manufacturer.
I was under impression that HP offered us a sweet deal on x64 servers (ProLiants) our management couldn't refuse. And why on earth run a Linux on proprietary hardware?
Old SPARCs would remain of course, but only for purposes of support and maintenance of old versions of our software.
We have bunch of old T2 - and they ... suck. Even on highly multithreaded Java workloads.
Is there a way for a CPU to make mutex handling easier and more efficient?
No. It is inherently expensive operation because the updates to critical section must be propagated between all the CPUs/cores (and their caches). CPU ops for mutex itself are puny, compared to the (invisible) mechanics beneath which guarantees the cache coherency. (More CPUs/cores you have - higher the potential overhead.)
Another thing which might be worth looking into speeding up is "gettimeofday" and "trigger on event or register/memory=certain value" - I bet there's lots of code which regularly checks "is it time to do X yet?" or "wait till X happens" (e.g. wait for connection or data).
`gettimeofday` is already optimized and not a real syscall on Linux and Solaris.
Maybe these aren't that CPU intensive so speeding them up won't help much in performance?
They are CPU intensive - but negligible - because they were already heavily optimized.
Overall, GP's suggestion that DB take lots of locks is sort of right - but misses the fact that there are many many locks so collisions are relatively rare. Those are most of the time logical data locks, not real mutexes. And collision are most of the time also of the logical nature: one user tries to update data which are currently being updated by another; one use tried to read data which were updated but not committed by the other; and so on.
DB are generally IO bound: they must provide guarantee that committed data were safely written to disk. This is where the most of DB's performance is wasted - waiting for the disk to do its job.
No no. You should familiriaze yourself with Oracle DB.
The CPUs are busy colliding on SQL statement cache global lock.
Am I missing something?
Has Sun produced any non-Tn CPU after UltraSPARC IV+ in 2005?
I haven't heard anything about UltraSPARC V - only the T line.
P.S. But probably I shouldn't care anymore. My company recently has just changed the "strategic platform" from Solaris 10 to RHL6.
Or more to the point: why organizations are picking RISCs at all?
Either Intel or author of RTFA is missing the point. Most organizations use RISC based systems which come as part of the business critical solutions. Hardware rarely accounts for 10% of the deal. Software licenses, deployment, testing and long term support are where the real money are.
Unless Intel introduces an architecture which it commits to support for at least one decade, I do not see a thing changing on corporate landscape. The problem with Intel boxes is that by the time you need a replacement part, the CPU/etc generation have already changed and one needs to replace the whole box. That obviously leads to the problem that you can't install the same tested old version of the OS and of the 3rd party crap - meaning that the whole solution has to be tested from ground up. It is not uncommon for such complete tests be worth more than 1000 person/days. Suddenly, replacement of a single $4000 server becomes a magnitudes more expensive affair.
P.S. But needless to mention that at least some part of the RISC stronghold was already dismantled: DB hosting for which now more and more Linux/x64 is used.
IANAL, but I have impression that you mixed up "copyright" and "authorship." Authorship is not transferable (except for plagiarism, obviously) - copyright is. And, as I understand it, always was: it isn't the author who is making copies of work, but a third party, e.g. publisher.