Slashdot Mirror

Let's think that through for a moment, the real conclusion is:
It does not matter which CA gets coerced.

A real solution to this problem that works actually works in modern browsers (Chrome 38+, Firefox 35+) is (even if not for every site, only for sites you regularly visit): HTTP Public Key Pining

http://blog.rlove.org/2015/01/...
___

I don't know if Let's encrypt needs any other CAs to partner with.

Their software is open source and their protocol is described and open. Other CAs can offer the same service.

I'm not a kid so I'd appreciate it if you dropped the tone ("...and this may come as a surprise"). I've been working on mobile development for quite a few years now.

I was a bit terse in my comment admittedly. What I meant with my comment is that Apple cannot allow multiple applications to run on that memory, unless they have rigorously tested each app: 256 MB is plenty of course (I was still doing development work on a laptop with half a gig just a couple of years ago), but not that much when you're running badly coded apps that do who knows what... I'm willing to bet real money that the fear of the OOM killer is why Apple (and most everyone else) is going through all this trouble.

You have to remember that 256 is the hard limit: there's no swap to rely on. Oh, and 256 includes the video memory as well...

Robert Love wrote good posts on this: 1, 2. rlove's not exactly the objective observer but the pieces are good.

jepaton here comments on embedded systems and what is possible with very little memory... that has no relevance here as, like I said, Apple has to run code created by idiots with no regard for resource use at all.

I'm not a kid so I'd appreciate it if you dropped the tone ("...and this may come as a surprise"). I've been working on mobile development for quite a few years now.

I was a bit terse in my comment admittedly. What I meant with my comment is that Apple cannot allow multiple applications to run on that memory, unless they have rigorously tested each app: 256 MB is plenty of course (I was still doing development work on a laptop with half a gig just a couple of years ago), but not that much when you're running badly coded apps that do who knows what... I'm willing to bet real money that the fear of the OOM killer is why Apple (and most everyone else) is going through all this trouble.

You have to remember that 256 is the hard limit: there's no swap to rely on. Oh, and 256 includes the video memory as well...

Robert Love wrote good posts on this: 1, 2. rlove's not exactly the objective observer but the pieces are good.

jepaton here comments on embedded systems and what is possible with very little memory... that has no relevance here as, like I said, Apple has to run code created by idiots with no regard for resource use at all.

It took me a minute to figure out what the hell this story had to do with Robert Love.

I'm no expert I'm afraid but I'll let I'll share with you what I know. The Linux I/O scheduler (which I believe turned up some time in the 2.6 era) is somewhat separate from the CPU scheduler (although there is a link in priority and timeslices). Thus it was always possible to drag a process doing I/O down by having something else perform enough disk I/O, especially if you are the root user. If you can make a system swap that will hurt things even more (and that's a form of I/O).

The thing to remember is that servicing certain types of I/O need not necessarily use up much CPU time. If a device is capable of doing DMA it will need comparatively little time from the CPU to be serviced (bigger transfers can happen while the CPU is off doing other things as opposed to have the device generating interrupts all the time that the CPU has to service before any more data is transferred because some temporary buffer is full and needs moving). Additionally, certain network drivers are able to do NAPI which can reduce CPU load during heavy transfers. The way that Linux handles interrupts (which have a top and bottom "half") allows the bottom half to happen in a process context (so the heavier part of the processing counts towards a process's timeslice). This is touched upon in on Robert Love's MMCSS entry. However, if you have an important process's I/O queued up behind something less important (and the low priority task is able to generate enough a big enough request for I/O on its timeslice) then the important processes may appear to go slower (effectively its latency will go up due to having to be passed over because its I/O isn't ready) despite having more CPU time assuming the hardware can't satisfy all the requests for I/O quickly enough (imagine big writes to a slow disk with deep queues and the task needing acknowledgement all the data made it to disk).

Depending on which I/O scheduler you picked and your hardware you may be able to alleviate this problem but that's not to say that things can't be improved (or that no one is complaining about the problem).

In short I would imagine the new CPU scheduler impact would be marginal improvement on I/O performance or latency under I/O load. If it was OK before it should still be OK (but bear in mind in memory virus scanning is a special case that I would imagine would make any OS go slower).

Google, Open Source Program Office, Boston: http://rlove.org/log/.

I am rather cross with you for lending your verbal support to Novell/Ximian's ignoble agenda to push KDE out of its well deserved and much loved position as the default desktop of the SuSE distribution. Which as you will recall, sparked a veritable customer revolt. How arrogant of you and those others involved. No, contrary to your claim [rlove.org], Ximian's offering is the second best Linux desktop, in my opinion. To be honest, I find Ximian's desktop downright irritating, clumsy, limited, buggy and really badly coded (yes I have been in there). However it is a fact that you have supported and continue to be an apologist for that cynical attempt to push KDE out of SuSE, that is not in doubt.

What is offtopic about that? It is a reasoned and honest response to the claim made on this page, linked from this article. On topic I say. And somebody with mod points yielded to the temptation to play the role of censor.

Hi Robert,

I am rather cross with you for lending your verbal support to Novell/Ximian's ignoble agenda to push KDE out of its well deserved and much loved position as the default desktop of the SuSE distribution. Which as you will recall, sparked a veritable customer revolt. How arrogant of you and those others involved. No, contrary to your claim, Ximian's offering is the second best Linux desktop, in my opinion. To be honest, I find Ximian's desktop downright irritating, clumsy, limited, buggy and really badly coded (yes I have been in there). However it is a fact that you have supported and continue to be an apologist for that cynical attempt to push KDE out of SuSE, that is not in doubt.

Regards,

Daniel

Jokes aside, MP3 playback for Linux actually used to be a headache and helped spur the development of Robert Love's preemptible kernel patches and many other enhancements to the scheduler and reductions of latency from the main Kernel team. You can see MP3 playback was used heavily as a diagnostic tool before these patches ended up in the vanilla kernel.

SMP machines with dual CPUs (or in this case, dual CPU cores) don't tend to have problems like that, so yes, having a dual core actually makes your MP3s sound better =)

Then again, if you're encoding your music collection to a crappy format like MP3, when you could be using far better formats (and more CPU intensive, where having a faster machine helps, too), then you don't really need them to sound better ;)

Robert Love is from the Ximian division (see here). He is also a kernel hacker. (See, e.g., here; see also here.) So, the comment may not have been sarcastic at all. Ximian actually does have at least one very accomplished Linux kernel hacker.

Ouch. I mean, given the bloated (but usable) mess that is Evolution, would you want those guys maintaining your distribution's kernel?

Maybe he is thinking about the Man instead?

Michael

1. SuSE: Gone and re-branded as Novel Linux Desktop. Now it's all tailored for business.

3. Linspire: Free unless you want to use the built in package management system. Then you have to pay for it.

I'd argue that they are indeed investing credible resources (if not "pumping money") into important parts of desktop infrastructure.

Robert Love working on HAL.
Robert O'Callahan working on Mozilla.
David Reveman working on Glitz/Cairo
Etc, etc.

NetworkManager or netapplet might help with that.