It's not DRM hacks that you have to worry about. P2P software will be simply modified to not share or download protected files. In the meantime, people will just stop downloading WMAs.
Wine has issues with practically every problem it runs. Even pinball is flickering and slow. I don't think you can rely on it for more stability than XP. If anything, running them under Win98, the original system they were written for, should be more help.
Don't scare me with the last paragraph. You mean, shoppers will have implanted RFIDs with their home address?
We're forgetting about one more group of readers
on
Science Askew
·
· Score: 1
Is there a geek joke here somewhere, that we think about 10% gay rather than hopefully more than 10% female slashdotters? Would make a good poll, except it would be a personal insult to CowboyNeal.
1. There is no spammer an existance who found it necessary to learn IP directly to optimize his/her "performance". Some abstractions are just good enough for everyone.
2. An abstraction may have many different implementations. Knowing details of just one doesn't solve the problem. For example, an associative array could use a hash table or a binary tree. Studying one implementation will not help me much to optimize performance under the other one.
3. When your pipes leak, you usually call a plumber. When you assumption leaks, you can call technical support of people providing it to you. This doesn't mean that it's worthwhile for most users of the assumption to know how to plumb themselves.
Why people need to know assembler then? Well, programming C/C++ is like having a model in which every car is missing major parts and no two are the same (different platforms/compilers). You are forced to "assemble" missing parts yourself. In addition, it crashes every time you make a wrong turn and the only way to find out why is to examine "parts" exposed during the crash.
On the other hand, I have written Java code that is reused between J2ME and J2EE (network protocols!). I don't know how the underlying OSes of various cell phones and app servers implement HTTP or threads and believe me, I don't want to know. If something doesn't work, I'll get on the phone and demand that the abstaction I use be freed of leaks and insects.
This is a kind of thing we are trying to fight
on
The Economics of Spam
·
· Score: 1
Sorry, but when I do something on Internet, I should only worry about the laws in the place I physically live. Even if I occasionally attend security conferences in other countries. Each of us breaks laws of some corner of the world on regular basis. If I go for a trip in Las Vegas, should I be arrested when returning to CA, where gambling is illegal?
The web site does say that firewire is for "testing real application clusters", although real is part of product name, not an insult.
I do wonder if a firewire cluster of high-end PCs will be any faster than one of it's components if it had an unshared, internal hard drive. Even if you have a bunch of old machines, it might be more tempting to buy a nice dual processor with tons of memory than spend more money buying firewire cards. Is firewire that fast that it's acceptable to use it for hard drive of the server big enough to need clustering?
You can beam a song to another Neuros, but only through FM. I tried a transmitter in my car before and couldn't get rid of constant hissing, no matter which frequency I chose.
I guess, at least in densly populated areas, this feature will be good for a demo but useless in practice. And I thought my dream of a bluetooth MP3 player that starts wireless P2P and leeches music matching preset criteria from it's neighbors just came true.
And just think about just how many DOS/Win3.1 stuff you could fit in 12MB RAM/540MB HD. Actually, I was running a regular Linux 1.x system with X on a machine like this a while ago and still kept a DOS partition.
I don't think this qualifies as a "feather weight" distributon. At least not in the same sense as the smallest ELF executable. Try a full featured UNIX system on a Palm, including editor, compiler and/usr/games, then it would be worth an article.
With just one word different and basically the same meaning. That site wasn't exactly socially conservative and was prominantly featured in a signature of a frequent slashdot user.
Ok, I am convinced. I am in the processes of creating a company that will apply pre-discovery to intellectual rights laws. The first step is hiring a large number of morbid alchoholics who will record their experiences while in creative mood and apply for patents. We don't have to spend money to develop actual products. Instead, someone will make a discovery later, develop the product and then pay us royalties.
Initial trials already yielded amazing results. A group of alchoholics from one of our larger international development centers is unanimous in pre-discovering a device that shrinks one's enemies and then forces them to go to a specific body part of the user. The developers were all trying to use this device on the product manager who was waking them up and asking them to verbalize their thoughts.
To apply, reply to this message with your own visions of the future. In compliance with local laws, potheads will be considered, but only if they have glucoma.
I guess I agree that we shouldn't do a context switch just for executing a single xchg instruction. But if the resource is busy, user level scheduler can not make a good decision. For one thing, it can only switch to threads in the same process where as kernel can make a global decision, such as switching to a process holding the resource we are waiting for. Also, user scheduler doesn't have execution statistics - working set, % of cpu slice used I/O behaviour etc - even for it's own threads. It can only do round-robin scheduling rather than optimizing potentian througput based on each thread's history.
I don't see how someone can say that "kernel thread scheduling" is slower than "user thread scheduling". Whatever algorithms pthreads library is using could also be used by a kernel process scheduler and offer the same benefits for daemons that fork() a lot of processes. Indeed, most of the time threads are not used to take advantage of multiple processors. Instead they are used in place of multiple processes with some shared memory that handle multiple requests at once. If they could be re-written to really be multiple processes with some shared memory, the resulting application will be simplier and possibly more stable/secure because only some portions would need to worry about concurrent access.
Conceptually, there is no reason why kernel code shouldn't use virtual memory, start system-use processes/threads, load shared libraries and so on. Or why "user" code shouldn't handle IRQs, call internal kernel functions or run in CPU supervisor code. Some tasks demand a certain programming model. For example, one would hope that a disk IRQ handler doesn't use virtual memory. But there is no need to place artificial restrictions to the point that multi-level schedulers and duplicated code are needed to run a nice Java web server.
If mainstream music is such a pain that I can't even listen to it while jogging with a portable player, I bet alternatives can succeed even without much marketing or policing P2P. All someone needs is a website selling CDs, MP3s and T-shirts. And of course low bit-rate free samples and/or shoutcast radio so that people can decide what to buy. The only catch is that they need to provide a variety or genres, not only "experimental noise", for which the market is probably saturated.
It's more likely though that once a lot of labels using copy-protected CDs, the remaining holdouts will see their sales sky-rocket and take notice. They will start selling CDs with a huge phillips logo on the package and running marketing campaings showing "everyday people" with MP3 players and scratched CDs making a switch.
Also, watch out for other countries recording music specially for US and european markets and selling cheap, working CDs. Mickey Mouse will soon be cornered by Hello Kitty:-)
Anyone else wishes their own company's internal memos showed such a firm grip on reality? I don't think Eric's comments really added anything to the document that wasn't already there. Basically, they released internal demo that says that most of their potential customers like Linux and there is nothing they can do about it.
Contrast this with our favourite CEO, who actually advocates competing with Microsoft by promoting use of their software. I think that the Haloween memos show a pretty healthy corporate culture.
Ironically, Linus may have to give up some control of his project precisely because he was so successful with it. With so many people using Linux, there will be times where he may personally disagree with some direction in kernel development (for example, binary compatible modules between releases... hint, hint. Or perhaps people really decide to re-write Linux as a microkernel:-) ).
The needs of a diverse user base would be better served by a group of developers with some way to discuss and vote on things that cause arguments. It doesn't have to be formal, but anyway one person shouldn't be able to force his/her opinion if everyone else disagrees.
Of course, Linus is saying that this kind of group can just maintain their own branch. But it will take a big event for people to start using a non-Linus branch and for developers to start submitting patches for it. And users will only loose when they found out that one branch doesn't crash and the other one crashes but supports their digital camera.
I guess it depends on weather Linus wants to keep his work as interesting as possible or put up with some annoying meetings and arguments to make the project as successful as possible. Of course, he has earned our blessing to do anything he wants. But I guess in the first case, someone will eventually make a branch with a critical improvement that he overlooked and Linux will end up as fragmented as *BSD.
I don't think it's reasonable for a small ISP to accept this kind of liability for what is supposed to be a recreational-use account. People like her, who use e-mail for critical business, should sign up for specialized business accounts that, for example, can offer loss ensurance, backup delivery of every message to another, independent ISP and will not block/disconnect service without 6-month prior notification. She will have to pay up of course, but it should be worth it if you are dealing with clients who will drop you because of one failed e-mail. Regular ISPs should only be liable for refund of service fee, perhaps with interest and compensation for the effort it took you to get the refund. Not for other, unpredictable, things that happened because you were locked out.
Perhaps the missile can contain a coolant that creates an especially dense fog when it evaporates. It will both make the mirror last longer and shield that missile from direct light. It will also be harder to actually hit the thing surrounded by a cloud.
Also I wonder what will happen to your laser gun if someone manages to reflect the light back to the source even for a second.
Now this one I am curious about. You can encrypt the filesystem, but then you need to store the key somewhere. Won't tamper-resistant hardware be more important than software at that point? Maybe Linux has a use for Palladium after all.
Well, I suggested disabling root account to avoid abuse by an individual, as a parent post implied. By giving your admin targetted setuid tools rather than root access you increase the chance that users' e-mail will be private.
It's the easiest to reply to your last paragraph. Indeed, exploits will be more difficult if only read-only pages would be executable by the CPU. But it's always possible to emulate the "required" secure hardware by running a VM. Java programs running on x86 will not have stack overrun problems, even if they are compiled to native code with gcj.
As for security of setuids and daemons - yes the code needs to be inspected, but no more than the equivalent kernel code of the "secure" OSes. If anything, most misuse will simply cause them to crash rather than bringing down the whole system as in the case of kernel bugs. And despite danger, setuid executables can provide very fine grained access control - such as truncating a specific log file, only if it's bigger than a certain size. Even a secure OS will only provide more basic priviliges that someone might find a way to escalate. I think providing a standard set of setuid programs that have been carefully reviewed and letting knowlegable people write more is better than hardcoding access control in the OS. UNIX has hit the mark as a "meta-OS" on top of which one can build a very secure or a very flexible environment.
You may have some point with chroot, but I don't see how kernel memory and processes will be compromized if you only have/dev/tty and don't mount/proc. If your IP filter works with loopback, you can deny access to your daemons from non-priviliged ports. Otherwise, they would indeed need to watch out for access from an chroot()ed process. I don't see what you can do to your parent process if it doesn't let you inherit any unintended file descriptors and simply calls wait(). As for giving users most of the OS, I assume that in a secure environment your users will only be able to access a fixed set of applications. Those executable files will be on a read-only filesystem, with the rest of the environment mounted as noexec,nodev. And UNIX does have process priorities and limits on memory, files, processes and so on. There may be bugs, but the basic concept is sound.
All I am saying is that it's possible to create a very secure UNIX distribution using standard system calls but carefully selected/reviewed user software. You will still get all the drivers and performance benefits of a general-purpose OS and have fine-grained options for balancing security and functionality.
Just disable the root account and install setuid programs or daemons to do specific functions for your administrator. If you have physical security, nobody will be able to actually login as root. Install an IP filter that only allows packets from priviliged ports if you don't want user's processes to user network directly. As for filesystem security, have users login to a chrooted account that only contains or mounts directories that they are supposed to access. How will this Unix installation be less secure than OSes you mentioned?
Perhaps you mean that default UNIX distributions you saw are not very secure. Or that system calls supported by your OSes encourage secure application design. But it should be still easier to write a library for this purpose under Linux than to write a whole new OS. What am I missing?
I suspect that they will tolerate it, in the same way as they tolerate OpenOffice opening DOC files and MP3 consortium doesn't make a RIAA-style effort to banish LAME. It's easier to collect money from someone who makes money (on a hardware player, game, music sales etc) and a free decoder can only encourage these businesses to use WMA.
Slashdot Mirror
It's not DRM hacks that you have to worry about. P2P software will be simply modified to not share or download protected files. In the meantime, people will just stop downloading WMAs.
Wine has issues with practically every problem it runs. Even pinball is flickering and slow. I don't think you can rely on it for more stability than XP. If anything, running them under Win98, the original system they were written for, should be more help.
Don't scare me with the last paragraph. You mean, shoppers will have implanted RFIDs with their home address?
1. There is no spammer an existance who found it necessary to learn IP directly to optimize his/her "performance". Some abstractions are just good enough for everyone.
2. An abstraction may have many different implementations. Knowing details of just one doesn't solve the problem. For example, an associative array could use a hash table or a binary tree. Studying one implementation will not help me much to optimize performance under the other one.
3. When your pipes leak, you usually call a plumber. When you assumption leaks, you can call technical support of people providing it to you. This doesn't mean that it's worthwhile for most users of the assumption to know how to plumb themselves.
Why people need to know assembler then? Well, programming C/C++ is like having a model in which every car is missing major parts and no two are the same (different platforms/compilers). You are forced to "assemble" missing parts yourself. In addition, it crashes every time you make a wrong turn and the only way to find out why is to examine "parts" exposed during the crash.
On the other hand, I have written Java code that is reused between J2ME and J2EE (network protocols!). I don't know how the underlying OSes of various cell phones and app servers implement HTTP or threads and believe me, I don't want to know. If something doesn't work, I'll get on the phone and demand that the abstaction I use be freed of leaks and insects.
Sorry, but when I do something on Internet, I should only worry about the laws in the place I physically live. Even if I occasionally attend security conferences in other countries. Each of us breaks laws of some corner of the world on regular basis. If I go for a trip in Las Vegas, should I be arrested when returning to CA, where gambling is illegal?
I do wonder if a firewire cluster of high-end PCs will be any faster than one of it's components if it had an unshared, internal hard drive. Even if you have a bunch of old machines, it might be more tempting to buy a nice dual processor with tons of memory than spend more money buying firewire cards. Is firewire that fast that it's acceptable to use it for hard drive of the server big enough to need clustering?
I guess, at least in densly populated areas, this feature will be good for a demo but useless in practice. And I thought my dream of a bluetooth MP3 player that starts wireless P2P and leeches music matching preset criteria from it's neighbors just came true.
I don't think this qualifies as a "feather weight" distributon. At least not in the same sense as the smallest ELF executable. Try a full featured UNIX system on a Palm, including editor, compiler and /usr/games, then it would be worth an article.
With just one word different and basically the same meaning. That site wasn't exactly socially conservative and was prominantly featured in a signature of a frequent slashdot user.
Initial trials already yielded amazing results. A group of alchoholics from one of our larger international development centers is unanimous in pre-discovering a device that shrinks one's enemies and then forces them to go to a specific body part of the user. The developers were all trying to use this device on the product manager who was waking them up and asking them to verbalize their thoughts.
To apply, reply to this message with your own visions of the future. In compliance with local laws, potheads will be considered, but only if they have glucoma.
I guess I agree that we shouldn't do a context switch just for executing a single xchg instruction. But if the resource is busy, user level scheduler can not make a good decision. For one thing, it can only switch to threads in the same process where as kernel can make a global decision, such as switching to a process holding the resource we are waiting for. Also, user scheduler doesn't have execution statistics - working set, % of cpu slice used I/O behaviour etc - even for it's own threads. It can only do round-robin scheduling rather than optimizing potentian througput based on each thread's history.
I don't see how someone can say that "kernel thread scheduling" is slower than "user thread scheduling". Whatever algorithms pthreads library is using could also be used by a kernel process scheduler and offer the same benefits for daemons that fork() a lot of processes. Indeed, most of the time threads are not used to take advantage of multiple processors. Instead they are used in place of multiple processes with some shared memory that handle multiple requests at once. If they could be re-written to really be multiple processes with some shared memory, the resulting application will be simplier and possibly more stable/secure because only some portions would need to worry about concurrent access. Conceptually, there is no reason why kernel code shouldn't use virtual memory, start system-use processes/threads, load shared libraries and so on. Or why "user" code shouldn't handle IRQs, call internal kernel functions or run in CPU supervisor code. Some tasks demand a certain programming model. For example, one would hope that a disk IRQ handler doesn't use virtual memory. But there is no need to place artificial restrictions to the point that multi-level schedulers and duplicated code are needed to run a nice Java web server.
It's more likely though that once a lot of labels using copy-protected CDs, the remaining holdouts will see their sales sky-rocket and take notice. They will start selling CDs with a huge phillips logo on the package and running marketing campaings showing "everyday people" with MP3 players and scratched CDs making a switch.
Also, watch out for other countries recording music specially for US and european markets and selling cheap, working CDs. Mickey Mouse will soon be cornered by Hello Kitty :-)
I don't know about icons and startup sequences, but I bet it's pretty good multimedia and a decent OS
Contrast this with our favourite CEO, who actually advocates competing with Microsoft by promoting use of their software. I think that the Haloween memos show a pretty healthy corporate culture.
The needs of a diverse user base would be better served by a group of developers with some way to discuss and vote on things that cause arguments. It doesn't have to be formal, but anyway one person shouldn't be able to force his/her opinion if everyone else disagrees.
Of course, Linus is saying that this kind of group can just maintain their own branch. But it will take a big event for people to start using a non-Linus branch and for developers to start submitting patches for it. And users will only loose when they found out that one branch doesn't crash and the other one crashes but supports their digital camera.
I guess it depends on weather Linus wants to keep his work as interesting as possible or put up with some annoying meetings and arguments to make the project as successful as possible. Of course, he has earned our blessing to do anything he wants. But I guess in the first case, someone will eventually make a branch with a critical improvement that he overlooked and Linux will end up as fragmented as *BSD.
Who can then buy a budget version and "upgrade" it with a ROM image from KazaaLite. Works every time.
I don't think it's reasonable for a small ISP to accept this kind of liability for what is supposed to be a recreational-use account. People like her, who use e-mail for critical business, should sign up for specialized business accounts that, for example, can offer loss ensurance, backup delivery of every message to another, independent ISP and will not block/disconnect service without 6-month prior notification. She will have to pay up of course, but it should be worth it if you are dealing with clients who will drop you because of one failed e-mail. Regular ISPs should only be liable for refund of service fee, perhaps with interest and compensation for the effort it took you to get the refund. Not for other, unpredictable, things that happened because you were locked out.
Uh-uh. Infinity Modulator display. Borg will run like hell.
Perhaps the missile can contain a coolant that creates an especially dense fog when it evaporates. It will both make the mirror last longer and shield that missile from direct light. It will also be harder to actually hit the thing surrounded by a cloud.
Also I wonder what will happen to your laser gun if someone manages to reflect the light back to the source even for a second.
Now this one I am curious about. You can encrypt the filesystem, but then you need to store the key somewhere. Won't tamper-resistant hardware be more important than software at that point? Maybe Linux has a use for Palladium after all.
Well, I suggested disabling root account to avoid abuse by an individual, as a parent post implied. By giving your admin targetted setuid tools rather than root access you increase the chance that users' e-mail will be private. It's the easiest to reply to your last paragraph. Indeed, exploits will be more difficult if only read-only pages would be executable by the CPU. But it's always possible to emulate the "required" secure hardware by running a VM. Java programs running on x86 will not have stack overrun problems, even if they are compiled to native code with gcj. As for security of setuids and daemons - yes the code needs to be inspected, but no more than the equivalent kernel code of the "secure" OSes. If anything, most misuse will simply cause them to crash rather than bringing down the whole system as in the case of kernel bugs. And despite danger, setuid executables can provide very fine grained access control - such as truncating a specific log file, only if it's bigger than a certain size. Even a secure OS will only provide more basic priviliges that someone might find a way to escalate. I think providing a standard set of setuid programs that have been carefully reviewed and letting knowlegable people write more is better than hardcoding access control in the OS. UNIX has hit the mark as a "meta-OS" on top of which one can build a very secure or a very flexible environment. You may have some point with chroot, but I don't see how kernel memory and processes will be compromized if you only have /dev/tty and don't mount /proc. If your IP filter works with loopback, you can deny access to your daemons from non-priviliged ports. Otherwise, they would indeed need to watch out for access from an chroot()ed process. I don't see what you can do to your parent process if it doesn't let you inherit any unintended file descriptors and simply calls wait(). As for giving users most of the OS, I assume that in a secure environment your users will only be able to access a fixed set of applications. Those executable files will be on a read-only filesystem, with the rest of the environment mounted as noexec,nodev. And UNIX does have process priorities and limits on memory, files, processes and so on. There may be bugs, but the basic concept is sound.
All I am saying is that it's possible to create a very secure UNIX distribution using standard system calls but carefully selected/reviewed user software. You will still get all the drivers and performance benefits of a general-purpose OS and have fine-grained options for balancing security and functionality.
Just disable the root account and install setuid programs or daemons to do specific functions for your administrator. If you have physical security, nobody will be able to actually login as root. Install an IP filter that only allows packets from priviliged ports if you don't want user's processes to user network directly. As for filesystem security, have users login to a chrooted account that only contains or mounts directories that they are supposed to access. How will this Unix installation be less secure than OSes you mentioned? Perhaps you mean that default UNIX distributions you saw are not very secure. Or that system calls supported by your OSes encourage secure application design. But it should be still easier to write a library for this purpose under Linux than to write a whole new OS. What am I missing?
I suspect that they will tolerate it, in the same way as they tolerate OpenOffice opening DOC files and MP3 consortium doesn't make a RIAA-style effort to banish LAME. It's easier to collect money from someone who makes money (on a hardware player, game, music sales etc) and a free decoder can only encourage these businesses to use WMA.