I whole-heartedly agree with what you say, but please keep in mind that no matter what the strategy, in the end, the DRM'ed content has to be accessible, and therefore can be grabbed and stripped of the DRM one way or another. Frankly, if the content is video, there is no "equivalent to showing an image of text". How would you go about it, hide the video and instead publish an audio file that describes the movie?;).
DRM is shit, and if the new DRM in firefox can't be disabled at runtime, then i'll disable it at compile time, and if it can't be disabled at compile-time, i'll patch it out. It's just probably not the end of freedom on the internet, for "us geeks" anyway. Maybe it is for average users, but as you correctly point out yourself, those tend to not care. So why care about them?
I don't see how it's a goalpost change since I didn't change your original statement except omitting the meaningless "you can think of" part. Now that it's clear that your argument actually (and intentionally, it seems) depended on me failing to think of sufficient such devices, then i don't think i want to continue this stupid conversation.
you have to admit that there are a very large number of commercial devices with busybox on them.
I don't deny that, but in comparison to the much greater number of commercial devices without busybox on them, it doesn't strik me as too significant.
You said it didn't get used commercially,
I also said this has gotten better lately. You should pay better attention since you obviously expect me to do the same.
There's an implicit "unless you *really* know what you're doing" to the sentence, which just tends to not be the case for most people, which is mainly because most people aren't crypto nerds, and the consequences of failing crypto are typically serious. Much more serious than doing your own science at home (provided you aren't going nuclear; "don't do your own nuclear science at home" doesn't sound so absurd, does it?) and ending up with wrong results, or composing music and ending up with horrible garbage.
Okay, let's hope the following doesn't whooosh over your head:
So examples are worthless now are they?
Yes, examples are worthless. A few comments up, I saw someone use systemd as an example for sticking with the UNIX philosophy. You really can't deny examples aren't worthless in the light of that, now, can you?
Apart from that, I'm still curious about your statement that
"busybox" is in just about every little device with a CPU you can think of.
Because you seem to be massively underestimating the amount of "little devices with a CPU" in existance which couldn't even run a fragment of busybox, apart from not having a need for it in the first place.
For example program A, a 1 megabyte program using ten 100KB pages is running. Those 100KB pages are loaded from disk when you start program A and are then executed. They are read-only, in that the contents of those pages do not change during the execution of program A.
During a context switch when program A is not running, program B is started, which loads three 100kb pages from disk. The OS then loads program B into the first three pages of the memory used by program A (after all, program A is not running *at* *this* *moment*). When the scheduler switches back to program A, the OS then reloads the first three pages of program A from the disk before program A starts running again. Another context switch later program B needs to run so the OS loads program B back into the first three pages of program A....
Thanks for the explanation, I didn't know this is actually a thing. It sounds slightly^W insane, though, mostly because (as you note yourself) how much longer disk I/O tends to take compared with context switches, or the timeslots remaining at typical scheduling frequencies..
If you need weird theories about what I "really" meant, when everything I said can be taken literally
That theory (which is not a theory, btw, please try and find out what a theory is) only stems from the fact that what you said, when taken literally, is complete and utter nonsense.
SysV init scripts are more monolithic than systemd.
Please try and find out what "monolithic" means.
Haters hate, and systemd haters hate for no reason. In fact, they are typically exactly 100% backwards in their complaints.
Pot, meet kettle.
And BTW kiddy, you might have noticed you weren't replying to an AC. Welcome to slashdot, brat.
Oh, indeed. I wonder why I assumed I was replying to AC... Probably it was the combination of demonstrating poor knowledge of the matter at hand in a loud and smug way, missing the point and the general crappiness of your comment. In fact, you'd probably be better of posting anonymously.
It should *still* read at most the same number of bytes as the first chunk of code.
Sure, although that assert is a no-op. It will never be wrong. If a no-op changes behavior of your program, then yes, it's either a compiler bug, or it's you having invoked undefined behaviour at some point and now the compiler doesn't need to hold on to its end of the deal anymore. I've seen too many "obvious compiler bugs" turn out to be no compiler bugs at all, so I tend to be careful with my conclusion. If that was indeed mid-late 90's MSVC++, then that makes it slightly easier to believe, yes;)
"/* ugly hack to... */" is a modest expression of pride describing concise, functional, readable and elegant C code...
Speak for yourself.
I usually use the expression "ugly hack" to describe the stupid shit I need to do to get around the consequences of relying on unspecified or undefined behavior in my code.
Slashdot Mirror
Care to elaborate what "Fixed" means in that chart?
Also, wow.
Whoosh.
Oh well.
If you think you're even close to enumerating the facebook DNS zone(s) there...well nevermind. I'm selling bridges, interested?
Oh shit, you're right. Thanks for helping me get my...oh whatever, go eat a dick, AC.
It's on *rails*.
So what? Ruby is, and still it crashes all the time, too.
It was lead, you pleb
s/ that one. :-)/./
A solar sail on an asteroid to change it's trajectory? You can't be serious.
in the end, the DRM'ed content has to be accessible
NO, IT DOESN'T.
What good is a movie, Mr. Anderson, if there's no way actually to watch it?
Yes! Hard elastic collisions please! Nevermind it completely shatters your body then instead of the car.
I whole-heartedly agree with what you say, but please keep in mind that no matter what the strategy, in the end, the DRM'ed content has to be accessible, and therefore can be grabbed and stripped of the DRM one way or another. ;).
Frankly, if the content is video, there is no "equivalent to showing an image of text". How would you go about it, hide the video and instead publish an audio file that describes the movie?
DRM is shit, and if the new DRM in firefox can't be disabled at runtime, then i'll disable it at compile time, and if it can't be disabled at compile-time, i'll patch it out. It's just probably not the end of freedom on the internet, for "us geeks" anyway. Maybe it is for average users, but as you correctly point out yourself, those tend to not care. So why care about them?
Stop the thoughtcrime already.
I don't see how it's a goalpost change since I didn't change your original statement except omitting the meaningless "you can think of" part. Now that it's clear that your argument actually (and intentionally, it seems) depended on me failing to think of sufficient such devices, then i don't think i want to continue this stupid conversation.
you have to admit that there are a very large number of commercial devices with busybox on them.
I don't deny that, but in comparison to the much greater number of commercial devices without busybox on them, it doesn't strik me as too significant.
You said it didn't get used commercially,
I also said this has gotten better lately. You should pay better attention since you obviously expect me to do the same.
There's an implicit "unless you *really* know what you're doing" to the sentence, which just tends to not be the case for most people, which is mainly because most people aren't crypto nerds, and the consequences of failing crypto are typically serious. Much more serious than doing your own science at home (provided you aren't going nuclear; "don't do your own nuclear science at home" doesn't sound so absurd, does it?) and ending up with wrong results, or composing music and ending up with horrible garbage.
What is this legitimate-ware you're speaking of and where do I get some?
The cost of searching for the right information again is generally higher than the cost of leaving the tab open.
I often reach a point where the cost of searching for the right tab is higher than the cost of searching for the right information again... :/
You're doing it wrong.
Okay, let's hope the following doesn't whooosh over your head:
So examples are worthless now are they?
Yes, examples are worthless. A few comments up, I saw someone use systemd as an example for sticking with the UNIX philosophy. You really can't deny examples aren't worthless in the light of that, now, can you?
Apart from that, I'm still curious about your statement that
"busybox" is in just about every little device with a CPU you can think of.
Because you seem to be massively underestimating the amount of "little devices with a CPU" in existance which couldn't even run a fragment of busybox, apart from not having a need for it in the first place.
For example program A, a 1 megabyte program using ten 100KB pages is running. Those 100KB pages are loaded from disk when you start program A and are then executed. They are read-only, in that the contents of those pages do not change during the execution of program A.
During a context switch when program A is not running, program B is started, which loads three 100kb pages from disk. The OS then loads program B into the first three pages of the memory used by program A (after all, program A is not running *at* *this* *moment*). When the scheduler switches back to program A, the OS then reloads the first three pages of program A from the disk before program A starts running again. Another context switch later program B needs to run so the OS loads program B back into the first three pages of program A....
Thanks for the explanation, I didn't know this is actually a thing. It sounds slightly^W insane, though, mostly because (as you note yourself) how much longer disk I/O tends to take compared with context switches, or the timeslots remaining at typical scheduling frequencies..
If you need weird theories about what I "really" meant, when everything I said can be taken literally
That theory (which is not a theory, btw, please try and find out what a theory is) only stems from the fact that what you said, when taken literally, is complete and utter nonsense.
SysV init scripts are more monolithic than systemd.
Please try and find out what "monolithic" means.
Haters hate, and systemd haters hate for no reason. In fact, they are typically exactly 100% backwards in their complaints.
Pot, meet kettle.
And BTW kiddy, you might have noticed you weren't replying to an AC. Welcome to slashdot, brat.
Oh, indeed. I wonder why I assumed I was replying to AC... Probably it was the combination of demonstrating poor knowledge of the matter at hand in a loud and smug way, missing the point and the general crappiness of your comment. In fact, you'd probably be better of posting anonymously.
PS: Please learn how to use grep(1)
a chunk of code such as:
unsigned char inbyte;
read(fd,&inbyte,sizeof(inbyte));
should always read at most the same number of bytes (one byte would be nice, but let's pretend we're non-POSIX, here...).
I'm not sure I'm following. If we're non-POSIX, then what read(2) are we talking about? Also, that sizeof is by definition 1
And if you *change* that chunk of code to something like, say:
unsigned char inbyte;
assert(sizeof(inbyte)==1);
read(fd,&inbyte,sizeof(inbyte));
It should *still* read at most the same number of bytes as the first chunk of code.
Sure, although that assert is a no-op. It will never be wrong. If a no-op changes behavior of your program, then yes, it's either a compiler bug, or it's you having invoked undefined behaviour at some point and now the compiler doesn't need to hold on to its end of the deal anymore. ;)
I've seen too many "obvious compiler bugs" turn out to be no compiler bugs at all, so I tend to be careful with my conclusion.
If that was indeed mid-late 90's MSVC++, then that makes it slightly easier to believe, yes
Could you elaborate on what exactly is wrong with the C garbage collector?
It occasionally unticks itself.
Speak for yourself.
I usually use the expression "ugly hack" to describe the stupid shit I need to do to get around the consequences of relying on unspecified or undefined behavior in my code.
FTFY