I think the phrase 'gaping remote code execution security hole' might be more appropriate.
Yes, how long until they fix it in a new release?
And, can somebody please assure me that I'll always be able to jailbreak the device? I'd hate it when I lost my phone and upon buying a new phone I'd discover that jailbreaking was not possible anymore.
Well replacing libc with a shim would not be very robust, since libc is entirely optional, and like you said, static binaries are making this approach fail.
(Of course, I could edit theose static ELF binaries, and replace the kernel calls, etc. But this seems to be totally not the right way (tm) to do it.)
Besides, having the ability to intervene at the interface between a process and the kernel, and hence be able to totally control the I/O behavior of a process, is something that, in my opinion, should be present in a modern OS. Think of all the possibilities for debugging, sandboxing, install-software, automatic dependency checking by build-tools, etc.
Thanks for the reply, but I really meant "recursive" strace.
The particular problem I have is that I want to make an installer which tracks all the write-operations of its child-processes. This can be easily done using strace. However, now imagine somebody else also writing an installer (also using strace), and using my installer as one of its child processes. On linux, this will fail.
Also imagine somebody else using strace to inspect what my installer is doing... this will also fail.
Isn't this what pthreads condition variables are for? Or can you explain what you want in more detail?
The main point is that it is now not easily possible to wait for both a file and a mutex, for example. A workaround could be waiting for a pipe, and writing to the pipe in a separate thread, but of course, this may become hairy.
From a user-space programmer's perspective, it would be nice to have the synchronization objects and file descriptors in the same id-space, but perhaps a simpler solution is possible.
Btw, thanks for the pointer to cgroups. I'm not sure if it entirely matches my needs, but I'll look into it.
anyway, you don't need any kernel anything for this feature. basic rule is if it can be done in user space, it very often ought to be done there.
Totally agree with you on the last part! However, this raises the rhetoric question why "nice" itself isn't totally handled inside libc:P
Also, such a feature should not be too difficult to add to the kernel. If it really would be difficult, then isn't the kernel getting just too complicated for its own good?
I think what linux needs is a way to internally associate the process id with each data-packet. Then, when a packet is routed through some bandwidth-limited channel (like your network card), the kernel could assign a priority to the packet based on the pid. But this is just an idea.
The iptables solution is just too simple, I think. Also, you have to invoke it as root.
However, only if I can run linux or android on it, I might buy an iPad. Yes, linux or andoid may not perform that well on this device (cpu and battery-wise), but the mere openness of these OSes is sufficient for me.
Since there seems to be no place on the internet where to post feature-requests for linux, here's four points from my list:
1. User-space scheduling. It would be nice if a process could have better control on the priority of each of its threads. For example, on a web service where multiple users are active, it is often necessary to give each user his/her share of the cpu. Right now this is rather difficult to do in a fair way, since multiple threads may belong to the same user.
2. Recursive strace: Currently it is not possible to run "strace" on a process which is already being straced. So for example: "strace -f strace -f ls" will not work (you'll get an "operation not permitted" inside the first strace. This makes it impossible for programs to use strace (or the related ptrace system call), since other programs which might also use strace, may depend on them.
3. "Nice" for bandwidth. It would be great if there was a command similar to "nice", which acts not on cpu-cycles but instead on bandwidth.
4. "Select" or "poll" with access to inter-thread synchronization structures. Select and poll are system calls which act mainly on file-descriptors. However, sometimes you'd like to wait also on a mutex or semaphore. Some support for this would be great.
This list is just from the top of my head. I could probably come up with a lot more.
It really should not be too difficult to create a nice tablet, as all the hardware has been produced already (see all the netbooks). Further, a tablet is really a lot like a smartphone, but you'll have a lot more freedom of design because of the bigger form factor (more room for battery etc).
Android could very well be used, with a few changes, like you said. MS should not be afraid to use it, as it really needs now to focus on breaking Apple's monopoly on the tablet market.
A better plan is to commoditize the tablet computer-market, just like PC's were commoditized in the 80's (and MS made a fortune out of that).
Having Apple controlling the standards is NOT a good idea.
So, what they should basically do, is offer a cheap but decent tablet computer. Perhaps even with linux or android on it, if they need to spend much more time on their own OS. Only then can they return to writing their own software for it.
Of course, this app store has been launched by Apple itself, and they will make it almost fail. I say almost, since they will try to keep only a critical mass of users, so no-one will attempt to make yet another app store.
Slashdot Mirror
wishful thinking...
Mod parent up!
Imagine what would happen if some piece of junk hits that garbage bag with a speed of 30.000 km per hour.
Hey now that google considers it useless, maybe they should open source it...
Can we have a similar ruling for Apple and AT&T please?
sorry but $69.99 for a book on Python programming is robbery. When I can get the same book on Amazon.com for $29.95.
...which also is like robbery, considering that you can find most information on the internet.
Agree with a lot you said. But my main concern is that shims are not robust. It is just waiting for some disaster going to happen.
You give all sorts of solutions, but the best solution is still to put it in the kernel, imho.
I think the phrase 'gaping remote code execution security hole' might be more appropriate.
Yes, how long until they fix it in a new release?
And, can somebody please assure me that I'll always be able to jailbreak the device?
I'd hate it when I lost my phone and upon buying a new phone I'd discover that jailbreaking was not possible anymore.
Well replacing libc with a shim would not be very robust, since libc is entirely optional, and like you said, static binaries are making this approach fail.
(Of course, I could edit theose static ELF binaries, and replace the kernel calls, etc. But this seems to be totally not the right way (tm) to do it.)
Besides, having the ability to intervene at the interface between a process and the kernel, and hence be able to totally control the I/O behavior of a process, is something that, in my opinion, should be present in a modern OS. Think of all the possibilities for debugging, sandboxing, install-software, automatic dependency checking by build-tools, etc.
Thanks for the reply, but I really meant "recursive" strace.
The particular problem I have is that I want to make an installer which tracks all the write-operations of its child-processes. This can be easily done using strace. However, now imagine somebody else also writing an installer (also using strace), and using my installer as one of its child processes. On linux, this will fail.
Also imagine somebody else using strace to inspect what my installer is doing... this will also fail.
Would this have any useful implications?
Any chance of this meaning the law of conservation of energy is flawed, for example?
Me too!
In fact, I'd take a decent movie made by a group of enthousiastic amateurs over any move produced by "big media", anytime.
Isn't this what pthreads condition variables are for? Or can you explain what you want in more detail?
The main point is that it is now not easily possible to wait for both a file and a mutex, for example. A workaround could be waiting for a pipe, and writing to the pipe in a separate thread, but of course, this may become hairy.
From a user-space programmer's perspective, it would be nice to have the synchronization objects and file descriptors in the same id-space, but perhaps a simpler solution is possible.
Btw, thanks for the pointer to cgroups. I'm not sure if it entirely matches my needs, but I'll look into it.
anyway, you don't need any kernel anything for this feature. basic rule is if it can be done in user space, it very often ought to be done there.
Totally agree with you on the last part! However, this raises the rhetoric question why "nice" itself isn't totally handled inside libc :P
Also, such a feature should not be too difficult to add to the kernel. If it really would be difficult, then isn't the kernel getting just too complicated for its own good?
Since there seems to be no place on the internet where to post feature-requests for linux
Which suggests a fifth point:
5. A place to post Linux feature requests! Also, a roadmap would be nice!
I think what linux needs is a way to internally associate the process id with each data-packet. Then, when a packet is routed through some bandwidth-limited channel (like your network card), the kernel could assign a priority to the packet based on the pid. But this is just an idea.
The iptables solution is just too simple, I think. Also, you have to invoke it as root.
Yes, and the iptables solution only works for root, if i'm correct.
This is a great step.
However, only if I can run linux or android on it, I might buy an iPad.
Yes, linux or andoid may not perform that well on this device (cpu and battery-wise), but the mere openness of these OSes is sufficient for me.
Since there seems to be no place on the internet where to post feature-requests for linux, here's four points from my list:
1. User-space scheduling. It would be nice if a process could have better control on the priority of each of its threads. For example, on a web service where multiple users are active, it is often necessary to give each user his/her share of the cpu. Right now this is rather difficult to do in a fair way, since multiple threads may belong to the same user.
2. Recursive strace: Currently it is not possible to run "strace" on a process which is already being straced. So for example: "strace -f strace -f ls" will not work (you'll get an "operation not permitted" inside the first strace. This makes it impossible for programs to use strace (or the related ptrace system call), since other programs which might also use strace, may depend on them.
3. "Nice" for bandwidth. It would be great if there was a command similar to "nice", which acts not on cpu-cycles but instead on bandwidth.
4. "Select" or "poll" with access to inter-thread synchronization structures. Select and poll are system calls which act mainly on file-descriptors. However, sometimes you'd like to wait also on a mutex or semaphore. Some support for this would be great.
This list is just from the top of my head. I could probably come up with a lot more.
Alex
It really should not be too difficult to create a nice tablet, as all the hardware has been produced already (see all the netbooks). Further, a tablet is really a lot like a smartphone, but you'll have a lot more freedom of design because of the bigger form factor (more room for battery etc).
Android could very well be used, with a few changes, like you said. MS should not be afraid to use it, as it really needs now to focus on breaking Apple's monopoly on the tablet market.
They don't need to create a quality product.
They only need to commoditize the tablet market.
Like they commoditized PC's in the 80's.
This will effectively destroy Apple's position. And MS can go back to developing software.
Not a good idea.
A better plan is to commoditize the tablet computer-market, just like PC's were commoditized in the 80's (and MS made a fortune out of that).
Having Apple controlling the standards is NOT a good idea.
So, what they should basically do, is offer a cheap but decent tablet computer. Perhaps even with linux or android on it, if they need to spend much more time on their own OS. Only then can they return to writing their own software for it.
Yes it was certainly old news, also considering the fact that Amazon came with a successful tablet device first.
Now Apple has succeeded in a major way at what Microsoft completely failed at, and boy, that must be embarrassing.
Yes, but it was merely an issue of the right timing. After all, Amazon prepared the market for a tablet-like device first. Only then came Apple.
Of course, this app store has been launched by Apple itself, and they will make it almost fail. I say almost, since they will try to keep only a critical mass of users, so no-one will attempt to make yet another app store.
How's that for a conspiracy theory? :P