The Debian project is alive and doing fine. It's true that it's no longer what comes to mind first or second when you think of a desktop Linux distribution, but declaring it killed is just plain wrong. Really. Calm down.
There's a time and place to go hooning, and it's called a very quiet road where no other traffic is, and where you're reasonably sure there are not cops lurking
If you want to drive fast, do it on a race track. Why the hell do you think there's a law against speeding? For the fun of it? IT'S BECAUSE IT KILLS INNOCENT PEOPLE!
I'm glad he put that bit up. I certainly hope they're going to charge him for it. People think they've got everything under control - and they have, 99.9999% of the time. Until they hit a hole in the road. Or somebody else does something stupid.:(
I don't know about the US, but in Denmark there's a company working on battery-changing infrastructure. So you drive into the station, get your empty batteries exchanged with fully charged ones from below by a robotic arm, then carry on.
That's not really true. You can push events right now.
The problem with the model on the web is that most clients are behind some kind of firewall/router/.... So the client always has to initiate the communication, keeping a connection open for the server to respond. What you do with long-polling is simply asking for events, not responding at the server until any events actually show up. Voila, event pushing. For this to work through standard HTTP, the clients sends a standard GET or POST and get back a properly formatted HTTP response.
From a cursory glance on websockets.org, it appears that the only thing web sockets is changing is making it simpler to send plain strings rather than complete HTTP messages. This solves the potential problem that when you get a response at the client, the (logical) connection is closed, so there's a gap until the client's next GET request arrives at the server before it can get a new event. So there's a limit to how fast you can receive the events, at least without some kind of trickery.
Possibly, the web sockets API might also make some connection issue problems simpler, but otherwise it's really not a big deal for most people.
I think most web servers won't ever serve sub-second events anyway, they're simple going to die from the load with many clients. Of course, in internal apps, the situation can be different. At lot of the new stuff in HTML5 is about extending the capabilities so web tech can supplant more of the traditional desktop apps.
I was thinking about this, but it might just be a penalty if your page loads really slow, say more than 10 seconds.
Google is still full of semi-dead links, when you click one, it takes forever to fetch the page - and half the time it never loads and the other half it doesn't load fully (so you get to see the ads, but not the content).
So there is less of an incentive to produce easy to use and bug free software?
Well, I think many pure support contracts are fixed-price, e.g. x $/month. So actually, it does make a lot of sense to cut down on the silly problems. I don't think you could sell it either, if it were crap - the open source world tends to be much more open, mistakes are slammed in public googleable forums.
Another thing is what goes under the hat "support". It's not just answering questions, it's also development of new features and integration, no different from the closed-source equivalent.
That's a common theory. The world was better in the good old days.
However, it has the flaw that you actually have a choice. And you chose to do what you're doing today. Maybe you think you've made bad choices, and maybe you have. But unless you really change your way of living, I think that's good evidence that you, when it really comes to it, don't regret much at all.
As I understand it, this is not just a GPU inside your CPU. This is a CPU with general parallel processing units integrated. Currently, if you want to take advantage of the parallel units inside GPUs, it's a PITA. In the future, it will hopefully be much, much easier with those units being inside the CPU.
So it's really about enabling a whole new area of computing that previously was too slow. 3D mesh graphics is not the only thing in this world that can be benefit from a beefy SIMD unit.
Of course, time will tell whether there's a market for this.
I'm hoping moving things into the CPU will make it easier to take advantage of the huge parallel architecture of modern GPUs.
For what, you ask?
I'm personally interested in sound synthesis. I play the piano, and while you can get huge sample libraries (> 10 GB), they're not realistic enough when it comes to the dynamics.
Instead people have been researching physical models of the piano. So you simulate a piano in software, or the main components of it, and extract the sound from that. Nowadays there are even commercial offerings, like Pianoteq (www.pianoteq.com) and Roland's V-Piano. Problem is that while this improves dynamics dramatically, they're not accurate enough yet to produce a fully convincing tone.
I think that's partly because nobody understands how to model the piano fully yet, at least judging from the research literature I've read, but also very much because even a modern CPU simply can't deliver enough FLOPS.
If you think smart pointers are braindead, it's no wonder you have such a bad experience with C++. They're one of the tools for keeping it simple. C++ is much more expressive than Java, it least it used to be, so there are certainly more ways of writing bad code. But also more ways of writing good code - so you can get closer to heaven.:)
In Denmark there's a so-called "council for more traffic safety", financed by the state. They keep track of where accidents happen and initiate public campaigns. Last year, 406 out of a population of app. 5.5 million died in a traffic accident. So that's about half the probability of being killed compared to the numbers for the US in the article you quote, but still 0.57% over a lifetime of 78 years.
That's actually a bit scary, I had no idea it was so high.
Javascript has been around for over 10 years now. Python predates Java with several years. Wake up! Java is not the end of the world, just because you made some effort to learn it doesn't mean everything must be written in it.
Also as if everything was standardized in systems programming. Yeah, because everybody is using C. Oh wait, C++. Oh wait, Java. Oh wait,.NET...
The problem is not internet/browser technology but their application on things that are not appropriate for it. The idea should be to use the internet for things we could not do before. Too bad most developers miss that basic premise.
Well, one of the important things we couldn't do before is run a game directly in the browser without installing anything. Maybe you don't think that's important, but it lowers the barrier to trying out a game considerably and completely sidesteps tedious issues of platform dependence. Browser-based games are potentially also much easier to enhance with multiplayer experiences, e.g. you could easily share custom levels.
Sure the browsers aren't quite up to the task yet. But if we don't keep pushing them, they'll never get there. And while jewel box games are perhaps still a bit far off, you can actually today write simpler games in Javascript.
Obviously, these are various ideas that may not turn up to be useful in practice. But it shows that an e-reader has the potential to actually enhance the reading experience as opposed to just being a less heavy version of the book. That's just amazing!
Regardless, I liked the fade-out-fill-words idea. I want a button for that in my browser!
PS: To all the nay-sayers: this is research (DFKI is a German research instution), it's not some company trying to sell you a product. Give them some slack.
Yeah, but on the other hand GUI is mostly about having a set of really, really fast routines to do the drawing and the whole lot of glue to do all the interface logic. Java's traditionally screwed up in the first part. Probably no amount of JIT'ing can save you then.:)
...and a version for legacy browsers that falls back on outdated rendering tricks
It doesn't have to be that grim. I've written a charting library for Javascript using the HTML canvas, and thank God some people have written an emulation library for IE so (most) things just work as expected when you include the library (and do a little secret dance). So I don't have to maintain two code bases. This can probably happen again. Never underestimate the momentum of thousands of angry developers.
I don't think the browsers are quite ready to replace Flash and similar for little arcade/action games, yet though, the real-time properties aren't good enough yet.
There was a paper some years ago about building the file system in such a manner that smaller files were placed on an SSD ( 1 MB) and large files were placed on a harddisk. At that time, SSDs were a lot smaller than today though.
Generally, it can make sense to discriminate your files because they don't all have the same space and access characteristics. Maybe 100 files is taking up 90% of the space compared to the other 9900 files. Maybe it's similar for the access pattern.
Still, for the idea to fly, you need to a robust algorithm and it needs to be clever about the strengths of the hardware. For instance, SSDs aren't so hot at random writes, sadly. Less than 0.1 msec write time would be neat for an ACID database.
A: "By the way, why don't people like us, and why can't I get a girlfriend?"
Well, it certainly seems you got the best of the bunch. "Honey, why does the computer act up?" "See, you need to press the little x on some of the windows." "WHAT?! THAT'S INSANELY COMPLICATED! FORGET IT!":)
I highly suspect they will NOT sell it with the giant rocket required for take off. Of course, if you're shelling out for the vehicle, rocket and launch platform gear is nothing, eh?
The bottom line is, whether you're talking about audio or video, more samples/sec or frames/sec is a good thing
No, it's not. You should never use more samples than actually needed. More samples means more data, which means slower processing which means you're wasting your cycles on something silly when you could use them for something better (like improving your other processing, or using cheaper/more low power equipment, or including more material, etc.).
The trick is to know how much is enough, of course.
Slashdot Mirror
The Debian project is alive and doing fine. It's true that it's no longer what comes to mind first or second when you think of a desktop Linux distribution, but declaring it killed is just plain wrong. Really. Calm down.
There's a time and place to go hooning, and it's called a very quiet road where no other traffic is, and where you're reasonably sure there are not cops lurking
If you want to drive fast, do it on a race track. Why the hell do you think there's a law against speeding? For the fun of it? IT'S BECAUSE IT KILLS INNOCENT PEOPLE!
I'm glad he put that bit up. I certainly hope they're going to charge him for it. People think they've got everything under control - and they have, 99.9999% of the time. Until they hit a hole in the road. Or somebody else does something stupid. :(
I don't know about the US, but in Denmark there's a company working on battery-changing infrastructure. So you drive into the station, get your empty batteries exchanged with fully charged ones from below by a robotic arm, then carry on.
That's not really true. You can push events right now.
The problem with the model on the web is that most clients are behind some kind of firewall/router/.... So the client always has to initiate the communication, keeping a connection open for the server to respond. What you do with long-polling is simply asking for events, not responding at the server until any events actually show up. Voila, event pushing. For this to work through standard HTTP, the clients sends a standard GET or POST and get back a properly formatted HTTP response.
From a cursory glance on websockets.org, it appears that the only thing web sockets is changing is making it simpler to send plain strings rather than complete HTTP messages. This solves the potential problem that when you get a response at the client, the (logical) connection is closed, so there's a gap until the client's next GET request arrives at the server before it can get a new event. So there's a limit to how fast you can receive the events, at least without some kind of trickery.
Possibly, the web sockets API might also make some connection issue problems simpler, but otherwise it's really not a big deal for most people.
I think most web servers won't ever serve sub-second events anyway, they're simple going to die from the load with many clients. Of course, in internal apps, the situation can be different. At lot of the new stuff in HTML5 is about extending the capabilities so web tech can supplant more of the traditional desktop apps.
I was thinking about this, but it might just be a penalty if your page loads really slow, say more than 10 seconds.
Google is still full of semi-dead links, when you click one, it takes forever to fetch the page - and half the time it never loads and the other half it doesn't load fully (so you get to see the ads, but not the content).
So there is less of an incentive to produce easy to use and bug free software?
Well, I think many pure support contracts are fixed-price, e.g. x $/month. So actually, it does make a lot of sense to cut down on the silly problems. I don't think you could sell it either, if it were crap - the open source world tends to be much more open, mistakes are slammed in public googleable forums.
Another thing is what goes under the hat "support". It's not just answering questions, it's also development of new features and integration, no different from the closed-source equivalent.
Why would they do it? it's all about saving money, it's not in the interests of passengers.
And saving money is not in the interests of the passengers?
It's funny that you think adult materials and the reformation were negative aspects.
That's a common theory. The world was better in the good old days.
However, it has the flaw that you actually have a choice. And you chose to do what you're doing today. Maybe you think you've made bad choices, and maybe you have. But unless you really change your way of living, I think that's good evidence that you, when it really comes to it, don't regret much at all.
As I understand it, this is not just a GPU inside your CPU. This is a CPU with general parallel processing units integrated. Currently, if you want to take advantage of the parallel units inside GPUs, it's a PITA. In the future, it will hopefully be much, much easier with those units being inside the CPU.
So it's really about enabling a whole new area of computing that previously was too slow. 3D mesh graphics is not the only thing in this world that can be benefit from a beefy SIMD unit.
Of course, time will tell whether there's a market for this.
I'm hoping moving things into the CPU will make it easier to take advantage of the huge parallel architecture of modern GPUs.
For what, you ask?
I'm personally interested in sound synthesis. I play the piano, and while you can get huge sample libraries (> 10 GB), they're not realistic enough when it comes to the dynamics.
Instead people have been researching physical models of the piano. So you simulate a piano in software, or the main components of it, and extract the sound from that. Nowadays there are even commercial offerings, like Pianoteq (www.pianoteq.com) and Roland's V-Piano. Problem is that while this improves dynamics dramatically, they're not accurate enough yet to produce a fully convincing tone.
I think that's partly because nobody understands how to model the piano fully yet, at least judging from the research literature I've read, but also very much because even a modern CPU simply can't deliver enough FLOPS.
If you think smart pointers are braindead, it's no wonder you have such a bad experience with C++. They're one of the tools for keeping it simple. C++ is much more expressive than Java, it least it used to be, so there are certainly more ways of writing bad code. But also more ways of writing good code - so you can get closer to heaven. :)
In Denmark there's a so-called "council for more traffic safety", financed by the state. They keep track of where accidents happen and initiate public campaigns. Last year, 406 out of a population of app. 5.5 million died in a traffic accident. So that's about half the probability of being killed compared to the numbers for the US in the article you quote, but still 0.57% over a lifetime of 78 years.
That's actually a bit scary, I had no idea it was so high.
Javascript has been around for over 10 years now. Python predates Java with several years. Wake up! Java is not the end of the world, just because you made some effort to learn it doesn't mean everything must be written in it.
Also as if everything was standardized in systems programming. Yeah, because everybody is using C. Oh wait, C++. Oh wait, Java. Oh wait, .NET...
For example, I can code/refactor and listen to a podcast just fine simultaneously.
Peopleware claims that programmers listening to music loose their creative dimension. Maybe your code isn't so good when you do that.
The problem is not internet/browser technology but their application on things that are not appropriate for it. The idea should be to use the internet for things we could not do before. Too bad most developers miss that basic premise.
Well, one of the important things we couldn't do before is run a game directly in the browser without installing anything. Maybe you don't think that's important, but it lowers the barrier to trying out a game considerably and completely sidesteps tedious issues of platform dependence. Browser-based games are potentially also much easier to enhance with multiplayer experiences, e.g. you could easily share custom levels.
Sure the browsers aren't quite up to the task yet. But if we don't keep pushing them, they'll never get there. And while jewel box games are perhaps still a bit far off, you can actually today write simpler games in Javascript.
Obviously, these are various ideas that may not turn up to be useful in practice. But it shows that an e-reader has the potential to actually enhance the reading experience as opposed to just being a less heavy version of the book. That's just amazing!
Regardless, I liked the fade-out-fill-words idea. I want a button for that in my browser!
PS: To all the nay-sayers: this is research (DFKI is a German research instution), it's not some company trying to sell you a product. Give them some slack.
I think the bigger news would be if they started work on a railway from China to the US.
That's because you live in the US. For those of us living in Europe, it's pretty big news.
Yeah, but on the other hand GUI is mostly about having a set of really, really fast routines to do the drawing and the whole lot of glue to do all the interface logic. Java's traditionally screwed up in the first part. Probably no amount of JIT'ing can save you then. :)
It doesn't have to be that grim. I've written a charting library for Javascript using the HTML canvas, and thank God some people have written an emulation library for IE so (most) things just work as expected when you include the library (and do a little secret dance). So I don't have to maintain two code bases. This can probably happen again. Never underestimate the momentum of thousands of angry developers.
I don't think the browsers are quite ready to replace Flash and similar for little arcade/action games, yet though, the real-time properties aren't good enough yet.
There was a paper some years ago about building the file system in such a manner that smaller files were placed on an SSD ( 1 MB) and large files were placed on a harddisk. At that time, SSDs were a lot smaller than today though.
Generally, it can make sense to discriminate your files because they don't all have the same space and access characteristics. Maybe 100 files is taking up 90% of the space compared to the other 9900 files. Maybe it's similar for the access pattern.
Still, for the idea to fly, you need to a robust algorithm and it needs to be clever about the strengths of the hardware. For instance, SSDs aren't so hot at random writes, sadly. Less than 0.1 msec write time would be neat for an ACID database.
The birth rate in wealthy nations gets very low, sometimes negative.
Negative birth rate? Oh yes. Nothing like getting back to your mother's womb.
:P
A: "By the way, why don't people like us, and why can't I get a girlfriend?"
Well, it certainly seems you got the best of the bunch. "Honey, why does the computer act up?" "See, you need to press the little x on some of the windows." "WHAT?! THAT'S INSANELY COMPLICATED! FORGET IT!" :)
Ole
I highly suspect they will NOT sell it with the giant rocket required for take off. Of course, if you're shelling out for the vehicle, rocket and launch platform gear is nothing, eh?
The bottom line is, whether you're talking about audio or video, more samples/sec or frames/sec is a good thing
No, it's not. You should never use more samples than actually needed. More samples means more data, which means slower processing which means you're wasting your cycles on something silly when you could use them for something better (like improving your other processing, or using cheaper/more low power equipment, or including more material, etc.).
The trick is to know how much is enough, of course.