But I don't want to rely on someone else's computer to run applications like Office, or Email, or games, or...anything I can think of right now.
I don't want to rely on someone else's computer to store my data.
Phrased differently, you just want to be independent, self-reliant, and keep things in control, which is absolutely normal.
I suppose the thing with most computer users these days is that since they don't feel like they're in control of anything they don't mind giving that away.
Why listening on multiple ports? Listening on a single port works just fine. All Bittorrent applications I ever used only required one port to be forwarded.
Take two thick, non-transparent pieces of paper. Write something on them. Now press them against your eyesockets, with text against the eyes, and try to read it. A bit dark for that, wouldn't you say?
Well with real paper the problem would rather be that you need to accommodate, which wouldn't be the case for a HMD.
You wouldn't press it against your eye sockets, you would wear it like regular glasses, also.
Watching a movie in a cinema? Sorry, please check your auxiliary "brain" at the counter first before you are allowed in.
A lot of movies are recorded with a camera in cinemas, and the video is not watchable. I guess that is proof the technology is not there yet. Ideally, the recorded version shouldn't look any different than reality.
If 10% of desktop computers are already running Linux, there is no room for discussion whether it is ready or not. It simply is, given the amount.
Now that amount is disputable, however.
As for the problems you are saying, all of them are irrelevant to the question except for sound crashes, which I personally never had (and I've set up quite a few ubuntus). People still say Windows is ready for the desktop though, even though every person that used it has had to endure a limitless amount of crashes.
So you're only saying your issue with Linux is hardware support. This of course is not Linux's fault but the manufacturer's.
Just get compatible hardware. Any decently smart person checks the hardware he buys is compatible with how he is going to use it. Laptops and printers are known to be the hardware with the most problems, because the products are very diverse and a lot of products are simply crap and thus not being bought by savvy people that can work out how to support them. Webcams and other random toy-like devices are also unlikely to work. For those you should search for a linux-compatible one, rather than checking whether a particular device is linux-compatible.
As far as I know, copyright law doesn't prevent me from doing what I want with the copies I own as far as I don't redistribute it.
Also, they could just say their computers were hacked by some anonymous person that put the file on peer-to-peer websites, hence it can be distributed illegally without them officially doing so.
All that remains is the DMCA that forced them to shut down their website because they explained how to "circumvent" copyright. They just have to choose a web hosting in a country that doesn't have that kind of stupid law and problem solved.
And where I am, you get unlimited 3G+ for less than 40 dollars per month. Oh yeah, and the carriers are giving out those cards for free when you subscribe.
Having a kernel thread per task doesn't work really well. A kernel thread uses more memory than a task, limiting inherently the maximum number of threads you can have (the thread stack being a problem, especially since it's quite hard not to take arbitrary sizes). It might also not be desirable to schedule everything at the same level when there are a lot of threads.
It is not useful to have more kernel threads than you have virtual processors (virtual processors being a generic term to address cores, hyperthreading, etc.) to benefit from hardware parallelization.
That's why it is advised to have tasks that run on available threads from a thread pool, rather than having a thread per task.
Another solution is N:M threading, with lightweight user-level threads, one for each task, spread across the finite number of kernel threads. That's what Erlang does, for example. It works even better if you put tasks with affinity together and build a tree of tasks, leading to hierarchic scheduling.
Now, none of these give you protection against badly-written code that leaks or crashes. Only process-based designs can do it, which is like a kernel thread for every task but with additional memory usage, and that's quite an overhead.
That's why people aren't doing it. Code should not leak or crash anyway, so that shouldn't be needed. Problem is, we can't really fix adobe flash without the source... But just putting flash in a separate process should be enough, I don't see any need to create a process per tab.
Plus the learning curve for functional languages is pretty high. Most programmers take a good bit of training to "get it", if they ever do
Personally, I find the functional way very nice and elegant. Functional languages also have a number of interesting proprieties in terms of genericity, safety, etc.
It's not especially harder than imperative, it's just a different vision. With proper studies for example it's not a problem. The problem is that from my experience, functional studies is mainly about theory such as lambda calculus classes, which non-theoricians are not that interested in.
I have been programming in Erlang for about 5 years and even though I get it, I still prefer the "normal" programming languages like C/C++, Lua, Perl, whatever. I use functional tricks and I wish some of those imperative languages had more functional features but I think they work more like the human mind does and that helps me program better.
My favourite language is personally C++, but I use functional techniques everyday, and that's often the way I recommend using that language.
For adoption it's important to allow coexistence of the two paradigms. The problem is that languages that allow both, such as SML or OCaml, aren't that good at imperative.
The reason people want FLAC for audio is simply to be on par with the CD version.
Really, if you've got the choice between acquiring the best quality there is and some "good enough" quality, for an insignificant price difference, what would you choose? Especially since acquiring a digital version means perpetual storage. People who care about what they are buying want the best there is, that's all there is to it.
As of today, you pay the same price, sometimes more, for a digital version than for a CD. There are many problems to this: - quality of digital version is lower, because it's compressed using a lossy codec - the rights you have on the copyrighted material are fewer than that of the CD version - DRM is used to enforce usage restrictions, and leads to a lot of problems - the mean of distribution is not open, you have to install dedicated proprietary software. On the other hand ordering a CD online or going to a store doesn't require anything out of you - you don't get the box, covers, pressed CD (that lives longer than custom burned CDs) etc.
Cost of a sale is virtually zero for the virtual store, while for a CD in a store it costs much more to produce and distribute. So they're reducing costs without reflecting it on price, making a huge margin.
So basically, you pay more for something that's worth much less.
The traditional way to code games is to have a CPU, that handles general-purpose game logic, and a GPU, which is a processor specialized in floating point vector operations, to handle the rendering. The thing is that typically, you cannot really use the GPU to do what you want, since most platforms only allow you to use it for rendering. CUDA and friends are trying to change that, but that GPUs are closed hardware which you can only use for rendering with a fixed pipeline remains true.
And here comes the Cell. The Cell is an open architecture (unlike GPUs) for floating point vector operations. Basically, a Cell is like an easy-to-use GPU, except you are truly free to program it the way you want. There are OpenGL drivers for the Cell that exist, but they're still experimental since quite academic. The PS3 SDK runs OpenGL on a separate GPU, mostly because nVidia has more experience in implementing an OpenGL stack.
But the real advantage of the Cell is in doing rendering in a different way than the traditional OpenGL fixed pipeline. Real-time raytracers, voxel-based engines, etc. become possible on the Cell. Or at least they would if people spent the time and budget on it.
It is also easier to accelerate physics and everything on the Cell, even though some ports of physics engines to GPUs exist.
The problem with the Cell is that it is really a research topic, and that it is not able to compete with the work GPUs sellers have done at the moment.
Also, I don't hang my hat on being straight - do you really need to point out that you're gay in your xbox profile? I mean... really?
You don't brag about being like everyone else, you only brag about what makes you special and different.
So that point is moot. If you were really gay, and proud of it, yes, you could want to say it everywhere to affirm your identity. But straight? Nothing special. No risk. No one cares. That's like bragging you've got brown eyes.
I was actually referring to basic graphical usage there.
The windowing system, where maximizing doesn't work, is just quite annoying, especially for browsing the Internet of stuff like that where fullscreen apps are better. Also the dock should really be set to auto-hide, because it feels very awkward otherwise with fullscreen apps. But then not always having the taskbar (or its equivalent) visible is also quite annoying to me, since I can't tell at a glance all the applications running. The fact that apps don't stay closed when you close them is another annoyance. The fact the menu is elsewhere is also quite annoying, since you have to be careful of focus and move the mouse across the screen. There is also the issue of weird keyboard layout and keyboard shortcuts. Basically all Fx keys are disabled unless you press the Fn key, and everything you usually use Ctrl for you now need to use the Option key instead, which is less practical to press in my opinion due to being more to the right of the keyboard.
I simply find the classical layout, with normal windows and a real taskbar, more efficient to work with, even for simple things such as browsing the web, editing a few text files and sending a few emails. Of course, I could tune Mac OS X to behave more like I would like to, but that's probably not worth the trouble since I scarcely use it.
Testing my little programs work from ssh is enough.
A Mac is a genuine Unix workstation that is much easier to administer, and has much better software and hardware support than Linux.
My girlfriend owns a mac laptop. From time to time, I use it, since I do not own a laptop but only a desktop computer. I just find it unusable, even to do the simplest of things. And I've actually spent time to read up on how Finder, Apps, the dock, and all those weird things work. Really, the only usable way to use a Mac I found is to connect to it with ssh. And it seems it's the case for a lot of other people, too, including Walter Bright.
If you walk into the computer science department at MIT, basically all the faculty have a Mac, and fully half the students do. These people are not buying Macs because they saw a cool ad on the bus - they're buying them because a Mac is the best tool available.
Or rather, the laptop world is so riddled with crap it is the less bad option. Basically, there are four choices: - IBM/Lenovo - Dell - Sony - Mac
Sony is usually not very competitive in terms of quality over price. IBM/Lenovo are the most reliable laptops out there, but they're too expensive. So it's down to Dell vs Mac.
Dell isn't that reliable for a linux setup. They do sell laptops with linux, but they're more expensive, have lower specs, and plainly suck. Plus Macs comes with one extra: you can run Mac OS X, which can be fairly difficult to do (and also quite illegal) with non-Apple hardware.
So at the end of the day, people choose Mac, especially students since they get good discounts.
A garbage collector is no silver bullet. It will protect you against hard leaks, but not logical leaks within your program.
You'd better design your resource management in terms of ownership from the start.
Somewhat less obvious is that a GC allows for by-reference assigments being the default.
You certainly do not need a GC to do that, assuming your functions are called synchronously. The reason pass-by-value is the default is mostly historic. Pass-by-const-reference is the recommended idiom.
We could redefine the default behavior as "pass a reference of b to a", but who will then take care of the lifetime of b?
b is guaranteed to outlive the reference we give to a, since a is called before b is destructed. Note this is not the case for asynchronous function calls, however.
Neither D nor C++ have them at the moment
They're doable as a DSEL. See FC++, Boost.Lambda, Boost.Phoenix, Boost.Phoenix v2...
but C++0x requires considerably more efforts to introduce them
Not considerably more effort, no. You just have to specify if you take your context by value, or take it by reference (and in that latter case, you have to ensure the referenced context outlives the closure).
D's template system has gone far beyond C++'s. It's even far beyond what C++0x is going to be
C++0x is mostly syntactic sugar. Nothing is really new. The most important new feature being rvalue references, to which D has no equivalent AFAIK.
Alias template parameters
You mean taking symbols as template parameters? You can do that in C++.
template mixins
You do them in C++ with templated inheritance.
a host of compile-time introspection facilities
C++0x concepts, which are really syntactic sugar for things that were already available in C++03, allow compile-time reflection, albeit in a limited way (you can check if something exist, but you cannot list everything that does exist).
type tuples
Unlike D, C++ does not add that kind of facility in the language, since it is doable as a library.
static if,
the ability to run regular functions at compile-time
D metaprogramming is to C++ metaprogramming as C++ OOP is to OOP in C. It takes a technique that the previous language begrudgingly permitted and turns it into one that is actually supported by the language.
That is overstating it. In C++, meta-programming is done using a functional programming style manipulating types, which are fully immutable, as values. In D, it's done just like regular programming, fuzzing the line between the two, except you have to make sure you add the keywords "static", "template" and the "!" operator in the right places. I personally prefer the C++ way. All in all, the D way of doing things at compile-time really looks like you have to write it as you were doing it at runtime and rely on the optimizer to work it out at compile-time. Look at variable arguments for example, they look more like C varargs than C++0x variadic templates.
On an unrelated note, any good C++ programmer I know finds that D has little to do with C++. It is closer to C, and closer to Java as well. Which are ironically the two worst ways to code in C++.
Slashdot Mirror
SQLite is fast all right, but it doesn't scale at all.
PostgreSQL scales well, but is fairly slow on average.
The thing with MySQL is that you were supposed to have both.
Phrased differently, you just want to be independent, self-reliant, and keep things in control, which is absolutely normal.
I suppose the thing with most computer users these days is that since they don't feel like they're in control of anything they don't mind giving that away.
Why listening on multiple ports?
Listening on a single port works just fine. All Bittorrent applications I ever used only required one port to be forwarded.
Well with real paper the problem would rather be that you need to accommodate, which wouldn't be the case for a HMD.
You wouldn't press it against your eye sockets, you would wear it like regular glasses, also.
A lot of movies are recorded with a camera in cinemas, and the video is not watchable.
I guess that is proof the technology is not there yet. Ideally, the recorded version shouldn't look any different than reality.
Why emit light in the first place?
Some display technologies, such as electronic paper, don't.
If 10% of desktop computers are already running Linux, there is no room for discussion whether it is ready or not.
It simply is, given the amount.
Now that amount is disputable, however.
As for the problems you are saying, all of them are irrelevant to the question except for sound crashes, which I personally never had (and I've set up quite a few ubuntus).
People still say Windows is ready for the desktop though, even though every person that used it has had to endure a limitless amount of crashes.
So you're only saying your issue with Linux is hardware support.
This of course is not Linux's fault but the manufacturer's.
Just get compatible hardware. Any decently smart person checks the hardware he buys is compatible with how he is going to use it.
Laptops and printers are known to be the hardware with the most problems, because the products are very diverse and a lot of products are simply crap and thus not being bought by savvy people that can work out how to support them.
Webcams and other random toy-like devices are also unlikely to work. For those you should search for a linux-compatible one, rather than checking whether a particular device is linux-compatible.
Linux is already 10% of the desktop.
All those things about it being not ready for the desktop are bullshit.
The only use there is in C++ for usage of memcpy is when you want to run afoul the strict aliasing rules.
Otherwise, you use std::copy.
They request that all work and copies be deleted.
As far as I know, copyright law doesn't prevent me from doing what I want with the copies I own as far as I don't redistribute it.
Also, they could just say their computers were hacked by some anonymous person that put the file on peer-to-peer websites, hence it can be distributed illegally without them officially doing so.
All that remains is the DMCA that forced them to shut down their website because they explained how to "circumvent" copyright.
They just have to choose a web hosting in a country that doesn't have that kind of stupid law and problem solved.
That's just an overpriced 3G+ card.
And where I am, you get unlimited 3G+ for less than 40 dollars per month.
Oh yeah, and the carriers are giving out those cards for free when you subscribe.
Having a kernel thread per task doesn't work really well. A kernel thread uses more memory than a task, limiting inherently the maximum number of threads you can have (the thread stack being a problem, especially since it's quite hard not to take arbitrary sizes). It might also not be desirable to schedule everything at the same level when there are a lot of threads.
It is not useful to have more kernel threads than you have virtual processors (virtual processors being a generic term to address cores, hyperthreading, etc.) to benefit from hardware parallelization.
That's why it is advised to have tasks that run on available threads from a thread pool, rather than having a thread per task.
Another solution is N:M threading, with lightweight user-level threads, one for each task, spread across the finite number of kernel threads. That's what Erlang does, for example.
It works even better if you put tasks with affinity together and build a tree of tasks, leading to hierarchic scheduling.
Now, none of these give you protection against badly-written code that leaks or crashes.
Only process-based designs can do it, which is like a kernel thread for every task but with additional memory usage, and that's quite an overhead.
That's why people aren't doing it. Code should not leak or crash anyway, so that shouldn't be needed. Problem is, we can't really fix adobe flash without the source... But just putting flash in a separate process should be enough, I don't see any need to create a process per tab.
Personally, I find the functional way very nice and elegant.
Functional languages also have a number of interesting proprieties in terms of genericity, safety, etc.
It's not especially harder than imperative, it's just a different vision. With proper studies for example it's not a problem. The problem is that from my experience, functional studies is mainly about theory such as lambda calculus classes, which non-theoricians are not that interested in.
My favourite language is personally C++, but I use functional techniques everyday, and that's often the way I recommend using that language.
For adoption it's important to allow coexistence of the two paradigms. The problem is that languages that allow both, such as SML or OCaml, aren't that good at imperative.
Nothing new is necessary.
Unicode already does it. You just need a proper Unicode font rendering backend.
The reason people want FLAC for audio is simply to be on par with the CD version.
Really, if you've got the choice between acquiring the best quality there is and some "good enough" quality, for an insignificant price difference, what would you choose?
Especially since acquiring a digital version means perpetual storage. People who care about what they are buying want the best there is, that's all there is to it.
As of today, you pay the same price, sometimes more, for a digital version than for a CD.
There are many problems to this:
- quality of digital version is lower, because it's compressed using a lossy codec
- the rights you have on the copyrighted material are fewer than that of the CD version
- DRM is used to enforce usage restrictions, and leads to a lot of problems
- the mean of distribution is not open, you have to install dedicated proprietary software. On the other hand ordering a CD online or going to a store doesn't require anything out of you
- you don't get the box, covers, pressed CD (that lives longer than custom burned CDs) etc.
Cost of a sale is virtually zero for the virtual store, while for a CD in a store it costs much more to produce and distribute.
So they're reducing costs without reflecting it on price, making a huge margin.
So basically, you pay more for something that's worth much less.
The Cell is not harder, it is just different.
The traditional way to code games is to have a CPU, that handles general-purpose game logic, and a GPU, which is a processor specialized in floating point vector operations, to handle the rendering.
The thing is that typically, you cannot really use the GPU to do what you want, since most platforms only allow you to use it for rendering. CUDA and friends are trying to change that, but that GPUs are closed hardware which you can only use for rendering with a fixed pipeline remains true.
And here comes the Cell. The Cell is an open architecture (unlike GPUs) for floating point vector operations.
Basically, a Cell is like an easy-to-use GPU, except you are truly free to program it the way you want.
There are OpenGL drivers for the Cell that exist, but they're still experimental since quite academic. The PS3 SDK runs OpenGL on a separate GPU, mostly because nVidia has more experience in implementing an OpenGL stack.
But the real advantage of the Cell is in doing rendering in a different way than the traditional OpenGL fixed pipeline.
Real-time raytracers, voxel-based engines, etc. become possible on the Cell. Or at least they would if people spent the time and budget on it.
It is also easier to accelerate physics and everything on the Cell, even though some ports of physics engines to GPUs exist.
The problem with the Cell is that it is really a research topic, and that it is not able to compete with the work GPUs sellers have done at the moment.
Also, I don't hang my hat on being straight - do you really need to point out that you're gay in your xbox profile? I mean... really?
You don't brag about being like everyone else, you only brag about what makes you special and different.
So that point is moot.
If you were really gay, and proud of it, yes, you could want to say it everywhere to affirm your identity.
But straight? Nothing special. No risk. No one cares. That's like bragging you've got brown eyes.
We have done a very good job explaining to folks what Linux is.'
They mean they've made people believe Linux is a cheap alternative to Windows, but not as good?
I was actually referring to basic graphical usage there.
The windowing system, where maximizing doesn't work, is just quite annoying, especially for browsing the Internet of stuff like that where fullscreen apps are better. Also the dock should really be set to auto-hide, because it feels very awkward otherwise with fullscreen apps. But then not always having the taskbar (or its equivalent) visible is also quite annoying to me, since I can't tell at a glance all the applications running.
The fact that apps don't stay closed when you close them is another annoyance.
The fact the menu is elsewhere is also quite annoying, since you have to be careful of focus and move the mouse across the screen.
There is also the issue of weird keyboard layout and keyboard shortcuts. Basically all Fx keys are disabled unless you press the Fn key, and everything you usually use Ctrl for you now need to use the Option key instead, which is less practical to press in my opinion due to being more to the right of the keyboard.
I simply find the classical layout, with normal windows and a real taskbar, more efficient to work with, even for simple things such as browsing the web, editing a few text files and sending a few emails.
Of course, I could tune Mac OS X to behave more like I would like to, but that's probably not worth the trouble since I scarcely use it.
Testing my little programs work from ssh is enough.
A Mac is a genuine Unix workstation that is much easier to administer, and has much better software and hardware support than Linux.
My girlfriend owns a mac laptop. From time to time, I use it, since I do not own a laptop but only a desktop computer.
I just find it unusable, even to do the simplest of things. And I've actually spent time to read up on how Finder, Apps, the dock, and all those weird things work.
Really, the only usable way to use a Mac I found is to connect to it with ssh. And it seems it's the case for a lot of other people, too, including Walter Bright.
If you walk into the computer science department at MIT, basically all the faculty have a Mac, and fully half the students do. These people are not buying Macs because they saw a cool ad on the bus - they're buying them because a Mac is the best tool available.
Or rather, the laptop world is so riddled with crap it is the less bad option.
Basically, there are four choices:
- IBM/Lenovo
- Dell
- Sony
- Mac
Sony is usually not very competitive in terms of quality over price. IBM/Lenovo are the most reliable laptops out there, but they're too expensive. So it's down to Dell vs Mac.
Dell isn't that reliable for a linux setup. They do sell laptops with linux, but they're more expensive, have lower specs, and plainly suck.
Plus Macs comes with one extra: you can run Mac OS X, which can be fairly difficult to do (and also quite illegal) with non-Apple hardware.
So at the end of the day, people choose Mac, especially students since they get good discounts.
C++ doesn't have many good libraries.
Qt is quite bad C++, for example, but will be for many the most beautiful C++ they ever see.
A garbage collector is no silver bullet. It will protect you against hard leaks, but not logical leaks within your program.
You'd better design your resource management in terms of ownership from the start.
Somewhat less obvious is that a GC allows for by-reference assigments being the default.
You certainly do not need a GC to do that, assuming your functions are called synchronously.
The reason pass-by-value is the default is mostly historic. Pass-by-const-reference is the recommended idiom.
We could redefine the default behavior as "pass a reference of b to a", but who will then take care of the lifetime of b?
b is guaranteed to outlive the reference we give to a, since a is called before b is destructed.
Note this is not the case for asynchronous function calls, however.
Neither D nor C++ have them at the moment
They're doable as a DSEL.
See FC++, Boost.Lambda, Boost.Phoenix, Boost.Phoenix v2...
but C++0x requires considerably more efforts to introduce them
Not considerably more effort, no.
You just have to specify if you take your context by value, or take it by reference (and in that latter case, you have to ensure the referenced context outlives the closure).
D's template system has gone far beyond C++'s. It's even far beyond what C++0x is going to be
C++0x is mostly syntactic sugar. Nothing is really new.
The most important new feature being rvalue references, to which D has no equivalent AFAIK.
Alias template parameters
You mean taking symbols as template parameters? You can do that in C++.
template mixins
You do them in C++ with templated inheritance.
a host of compile-time introspection facilities
C++0x concepts, which are really syntactic sugar for things that were already available in C++03, allow compile-time reflection, albeit in a limited way (you can check if something exist, but you cannot list everything that does exist).
type tuples
Unlike D, C++ does not add that kind of facility in the language, since it is doable as a library.
static if,
the ability to run regular functions at compile-time
D metaprogramming is to C++ metaprogramming as C++ OOP is to OOP in C. It takes a technique that the previous language begrudgingly permitted and turns it into one that is actually supported by the language.
That is overstating it. In C++, meta-programming is done using a functional programming style manipulating types, which are fully immutable, as values. In D, it's done just like regular programming, fuzzing the line between the two, except you have to make sure you add the keywords "static", "template" and the "!" operator in the right places.
I personally prefer the C++ way.
All in all, the D way of doing things at compile-time really looks like you have to write it as you were doing it at runtime and rely on the optimizer to work it out at compile-time. Look at variable arguments for example, they look more like C varargs than C++0x variadic templates.
On an unrelated note, any good C++ programmer I know finds that D has little to do with C++. It is closer to C, and closer to Java as well. Which are ironically the two worst ways to code in C++.
What else?
(no, I'm not George Clooney)