"'thought society was no longer looking at higher education as a common good but rather as a way for individuals to increase their earning power.'"
Because everyone majoring in "Communications" is fulfilling a lifelong dream and not just there for the degree.
Pssh. Anybody with a library and curiosity can learn all the art history they want to, it's not particularly difficult, nor do you need to pay a college tuition to have a discussion about it.
The real shame here is that people might be dissuaded from learning something they would have a much more difficult time learning on their own, due to the cost.
I have a feeling, though, that the pre-season 1 events will play a large part in the rest of the show, and giving them away now might give away too much.
I think it's going to be really tough to make a game that fans will be happy with and not reveal too much about the show. We'll see how they do.
Deflation is just as bad for an economy, possibly even worse, than inflation, because when you have deflation there's much less incentive to invest money instead of hoarding it.
I know you're being facetious, but after going car shopping, this is indeed a big problem.
Part of the reason that Honda and Toyota became so popular was that they had a small selection of cars, all of them decent.
Ford has a huge selection of cars, some great, some awful, and Ford replicates most models across different brand names, so that the Mercury Mountaineer is a re-branded Ford Explorer with a completely different set of options available.
It's really pointless - I don't want to have to sift through thousands of models and options to get what I want.
Car manufacturers are a good example of what not to do.
CDMA is a physical layer protocol. You wouldn't ever do CDMA "over" IP.
You might want to have a phone that's able to transmit a CDMA signal and *also* an 802.11 signal, so you could connect to cell networks and LANs with the same device. If your network were coordinated well enough such that you could transfer calls between VOIP and the cellular network, that would be a big step, and seems to be what the grandparent was talking about.
You're right, it just seems to me that with a micro-kernel there would be greater separation of tasks and the granularity problem would be a lot easier. If processes are separated, the complex locking doesn't need to occur.
I'm thinking about this more from a software engineering standpoint. Multi-threaded programming is more difficult, and I think when the number of cores increases significantly, the performance advantage will no longer be great enough to be worth the programmer's time.
In terms of concurrent memory access, threads are unsafe by default -- you have to do a lot of extra work to make them safe, but they're fast by default also. But you do pay a performance penalty if you err on the side of "too safe."
Processes are safe by default, but you have to do extra work to make them perform.
I think finding the bottlenecks in performance with processes will be easier in the future than implementing perfect locking in threads.
"Locks, mutexes, and other synchronization constructs are necessary to synchronize access to memory under all circumstances where multiple execution contexts (that is, multiple threads or multiple processes) share data."
I didn't mean to imply that processes don't need to use locks, etc. when sharing data. But processes are protected a lot more from this in the common case by virtue of the fact that they don't share address spaces.
Sure, if you are using shared memory between processes, you'll need to protect access to it the same way as you would with threads.
The problem with threads is that all of the memory has the potential to be accessed by any other thread, which is a lot more unsafe, even if you're trying to do the right thing. So in the case of C program that has a potential security flaw or bug (i.e. all of them), you have to treat all memory as if it can be accessed by any thread at any time, in order to be certain that nothing goes wrong.
Take, for example, a web browser with a thread that accesses the network -- if there were a vulnerability in that thread, the whole browser process is now compromised. If the browser launched a separate process to get network data, it's isolated from the rest of the browser and has a reduced ability to cause damage.
For clarity, when I talk about threads and processes, I define them as follows: A process is an execution context with it's own virtual address space. A thread is an execution context that exists in the same address space as other threads, but has its own control stack.
The only real difference between a thread and a process the way I've defined them is how memory is mapped. Shared memory blurs the difference.
The big advantage with threads is that the TLB doesn't have to be flushed on a context switch, since they share the same address space. This has great performance advantages over processes, but you lose all of the advantages of protected virtual memory, hence the need for locks, mutexes, critical sections, etc. Threads are actually a step backward from a reliability/security standpoint.
BeOS was a single-user system, if I recall, so that partially reduces the need for the security features that having multiple processes provide.
But beyond that, modern OS's seem to offer a lot more flexibility. They have processes if you want separation of address space, shared memory if you need better performance for communication between threads, threading if you want a shared address space, and user-level threading libraries for the ultimate in performance if you're willing to spend the time to code it properly.
Being able to watch eight movies at a time is a neat trick, but it's not particularly useful, especially when we'll soon have processors with a ridiculous amount of cores on them. With a large number of cores, the overhead of a process context switch is hardly more than that of a thread, since a CPU intensive process can run on its own core.
I think the future of OS's is more likely to be in micro-kernel architectures that can move processes around efficiently to balance the processing load between many CPUs. Or a hybrid microkernel/monolithic architecture that could run the big kernel on one CPU for tasks that require responsiveness, and the rest of the kernel processes balanced between remaining CPU's for throughput.
"I'm in the minority because I like the Bush administration"
So YOU'RE the one.:-)
But honestly, for the life of me, I can't think of a reason any group has not to dislike what Bush has done. Liberals hate him by default, he's no conservative, he's done nothing for the libertarians...and he went to war without planning for the inevitable eventuality that the spineless half of the country would stab him in the back when the going got tough.
I'll even give him the benefit of the doubt and say he's a well-intentioned person who's just a bit too optimistic, and that screws things up for him.
But given that, what is there to like? Are you a recently expatriated Iraqi in the U.S. with a Mexican illegal immigrant employer who suddenly needed a Medicare prescription drug plan?
I'm with you here. Nine years ago, PostgreSQL was so far ahead of MySQL in terms of features (basic things like foreign keys didn't exist in MySQL) it wasn't even a contest deciding to go with Postgres.
MySQL has only recently mostly caught up in the feature department, so for any real database work up until that time, Postgres was the only sane choice.
The awful thing still about MySQL is that because of the way it's put together, it's a crap shoot as to what features are going to be installed if you don't own the server you're working on. Any database that makes me wonder, "are foreign keys supported in this version?" is not worth using when there are alternatives.
I'm sure MySQL has its uses, but every time I work with it, I get pissed off at how many features are missing, or how badly it handles complex queries. The fact that, "Oh, the newest version of MySQL has that now too, if you use InnoDB tables!" is no consolation.
Slashdot Mirror
I'm sure you enjoy banging rocks together outside in the forest, but culture and engineering for most people are fairly symbiotic.
"'thought society was no longer looking at higher education as a common good but rather as a way for individuals to increase their earning power.'"
Because everyone majoring in "Communications" is fulfilling a lifelong dream and not just there for the degree.
Pssh. Anybody with a library and curiosity can learn all the art history they want to, it's not particularly difficult, nor do you need to pay a college tuition to have a discussion about it.
The real shame here is that people might be dissuaded from learning something they would have a much more difficult time learning on their own, due to the cost.
First of all, how many programs have command line parsing as a bottleneck?
Secondly, they should put this functionality into GCC instead, so that it creates a perfect hash for any large switch statement.
That's a great idea.
I have a feeling, though, that the pre-season 1 events will play a large part in the rest of the show, and giving them away now might give away too much.
I think it's going to be really tough to make a game that fans will be happy with and not reveal too much about the show. We'll see how they do.
Deflation is just as bad for an economy, possibly even worse, than inflation, because when you have deflation there's much less incentive to invest money instead of hoarding it.
$20 games that were $60 games last year here to stay too.
...why the upscaling has been limited to HDMI only?
I was excited about the last update but use component so it did nothing for me. Unless I missed something.
The OS can already do everything that an OS can do.
Stop trying to reinvent the wheel.
Online office apps are pointless once somebody offers decent, cross platform, ad supported storage of data.
I know you're being facetious, but after going car shopping, this is indeed a big problem.
Part of the reason that Honda and Toyota became so popular was that they had a small selection of cars, all of them decent.
Ford has a huge selection of cars, some great, some awful, and Ford replicates most models across different brand names, so that the Mercury Mountaineer is a re-branded Ford Explorer with a completely different set of options available.
It's really pointless - I don't want to have to sift through thousands of models and options to get what I want.
Car manufacturers are a good example of what not to do.
"Just because they finally put out a stable OS we are supposed to stay with them and their mistakes forever?"
But why make your dad change if XP works and he's happy with it?
Don't try to fix what isn't broken. If there's ANY problem with the Linux you replace XP with, your dad will blame you.
>my cat just traipsed on my keyboard and typed "dsafhhrnvcdbqwtrwqerwe897509k;ln b,.cnjhcvdsytwejbhd"
I've read that one, it sucked. The butler did it and they catch him in the end.
Your cat should have typed Hamlet.
"our future explorers will be playing WOW all the way to Alpha Centauri"
Not me. I'll be playing Alpha Centauri all the way to . . . Alpha Centauri.
Dammit. If WOW were a solar system, that would have been a lot funnier.
He won't :-)
Don't worry, you'll get another chance yesterday.
CDMA is a physical layer protocol. You wouldn't ever do CDMA "over" IP.
You might want to have a phone that's able to transmit a CDMA signal and *also* an 802.11 signal, so you could connect to cell networks and LANs with the same device. If your network were coordinated well enough such that you could transfer calls between VOIP and the cellular network, that would be a big step, and seems to be what the grandparent was talking about.
"Multiplying combat effectiveness" is military jargon for "it works better than the previous way."
It's kind of like saying, "this is more proactive, and network-centric."
You're right, it just seems to me that with a micro-kernel there would be greater separation of tasks and the granularity problem would be a lot easier. If processes are separated, the complex locking doesn't need to occur.
I'm thinking about this more from a software engineering standpoint. Multi-threaded programming is more difficult, and I think when the number of cores increases significantly, the performance advantage will no longer be great enough to be worth the programmer's time.
In terms of concurrent memory access, threads are unsafe by default -- you have to do a lot of extra work to make them safe, but they're fast by default also. But you do pay a performance penalty if you err on the side of "too safe."
Processes are safe by default, but you have to do extra work to make them perform.
I think finding the bottlenecks in performance with processes will be easier in the future than implementing perfect locking in threads.
"Locks, mutexes, and other synchronization constructs are necessary to synchronize access to memory under all circumstances where multiple execution contexts (that is, multiple threads or multiple processes) share data."
I didn't mean to imply that processes don't need to use locks, etc. when sharing data. But processes are protected a lot more from this in the common case by virtue of the fact that they don't share address spaces.
Sure, if you are using shared memory between processes, you'll need to protect access to it the same way as you would with threads.
The problem with threads is that all of the memory has the potential to be accessed by any other thread, which is a lot more unsafe, even if you're trying to do the right thing. So in the case of C program that has a potential security flaw or bug (i.e. all of them), you have to treat all memory as if it can be accessed by any thread at any time, in order to be certain that nothing goes wrong.
Take, for example, a web browser with a thread that accesses the network -- if there were a vulnerability in that thread, the whole browser process is now compromised. If the browser launched a separate process to get network data, it's isolated from the rest of the browser and has a reduced ability to cause damage.
For clarity, when I talk about threads and processes, I define them as follows: A process is an execution context with it's own virtual address space. A thread is an execution context that exists in the same address space as other threads, but has its own control stack.
The only real difference between a thread and a process the way I've defined them is how memory is mapped. Shared memory blurs the difference.
You're welcome.
Have fun with basic-256, and let me know if I can help at all.
The big advantage with threads is that the TLB doesn't have to be flushed on a context switch, since they share the same address space. This has great performance advantages over processes, but you lose all of the advantages of protected virtual memory, hence the need for locks, mutexes, critical sections, etc. Threads are actually a step backward from a reliability/security standpoint.
BeOS was a single-user system, if I recall, so that partially reduces the need for the security features that having multiple processes provide.
But beyond that, modern OS's seem to offer a lot more flexibility. They have processes if you want separation of address space, shared memory if you need better performance for communication between threads, threading if you want a shared address space, and user-level threading libraries for the ultimate in performance if you're willing to spend the time to code it properly.
Being able to watch eight movies at a time is a neat trick, but it's not particularly useful, especially when we'll soon have processors with a ridiculous amount of cores on them. With a large number of cores, the overhead of a process context switch is hardly more than that of a thread, since a CPU intensive process can run on its own core.
I think the future of OS's is more likely to be in micro-kernel architectures that can move processes around efficiently to balance the processing load between many CPUs. Or a hybrid microkernel/monolithic architecture that could run the big kernel on one CPU for tasks that require responsiveness, and the rest of the kernel processes balanced between remaining CPU's for throughput.
Obviously, you didn't grow up playing Ghosts n' Goblins.
How many games today contain the message "You lose. Start over."?
That was almost every game back in the 80's. Lost to the final boss? Start at the beginning.
"I'm in the minority because I like the Bush administration"
:-)
So YOU'RE the one.
But honestly, for the life of me, I can't think of a reason any group has not to dislike what Bush has done. Liberals hate him by default, he's no conservative, he's done nothing for the libertarians...and he went to war without planning for the inevitable eventuality that the spineless half of the country would stab him in the back when the going got tough.
I'll even give him the benefit of the doubt and say he's a well-intentioned person who's just a bit too optimistic, and that screws things up for him.
But given that, what is there to like? Are you a recently expatriated Iraqi in the U.S. with a Mexican illegal immigrant employer who suddenly needed a Medicare prescription drug plan?
I'm with you here. Nine years ago, PostgreSQL was so far ahead of MySQL in terms of features (basic things like foreign keys didn't exist in MySQL) it wasn't even a contest deciding to go with Postgres.
MySQL has only recently mostly caught up in the feature department, so for any real database work up until that time, Postgres was the only sane choice.
The awful thing still about MySQL is that because of the way it's put together, it's a crap shoot as to what features are going to be installed if you don't own the server you're working on. Any database that makes me wonder, "are foreign keys supported in this version?" is not worth using when there are alternatives.
I'm sure MySQL has its uses, but every time I work with it, I get pissed off at how many features are missing, or how badly it handles complex queries. The fact that, "Oh, the newest version of MySQL has that now too, if you use InnoDB tables!" is no consolation.
>Upconverting (1080i) DVD player
Huh? My PS3 doesn't do this.
Excuse me for replying to my own post, but there's a grammar error.
<hand on hips>
They bettah check THEYselves, because they a bunch a' stank hoes over at Minisodes. MmmmmHMMM!
</hand on hips>
Thank you for your time.