Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment: Re:The study was flawed (Score 5, Informative) 90

by Guy Harris (#49548257) Attached to: Bees Prefer Nectar Laced With Neonicotinoids

The study compared Neonicotinoids laced pollen to sugar water. Which means it was not a fair comparison. There needs to be a comparison between Neonicotinoids laced pollen and unlaced pollen.

No, the study compared neonicotinoid-laced sugar water with sugar water:

Individual foraging-age worker bumblebees or cohorts of 25 forager honeybees were housed in plastic boxes for 24 h and given access to two types of food tubes: one containing sucrose solution and one containing sucrose solution laced with a specific concentration of the[sic] IMD, TX, or CLO.

(If you follow the "bees prefer nectar laced with neonicotinoids" link in the /. article and then the "the insects tended to eat more of the contaminated food" link from the article you get to after following that link, you can read the paper without going through a paywall.)

So, no, it's not a comparison between neonicotinoid-laced pollen and pollen, but it's also not a comparison between (neonicotinoid-laced) pollen and sugar water.

Comment: Re:Comcast and Time Warner, a match made in . . . (Score 1) 112

by Guy Harris (#49546341) Attached to: Comcast Officially Gives Up On TWC Merger

I can't even get past the fact that the TWC - AOL merger was labeled the worst in the entire history of the US and then they went for a second indentical title with Comcast. Who the hell is running things at Time Warner?

Different people from the ones who are running things at Time Warner Cable, as Time Warner Cable was spun off from Time Warner in 2009. (And Time Warner has nothing to do with Time Magazine; that's now a product of Time Inc.)

Comment: Re:Google: Select jurors who understand stats. (Score 1) 339

by Guy Harris (#49543401) Attached to: Median Age At Google Is 29, Says Age Discrimination Lawsuit

"our skills actually create value." But legal skills create money. Most people would choose money over value (would you like $100 in fiat currency or 40 loaves of bread?).

I might go for the 40 loaves of bread, if I could sell them for more than $100.

On the other hand, I might choose a Fiat 500 over either of them.

Comment: Re:Please, BCE/CE, not BC/AD (Score 4, Funny) 105

by Guy Harris (#49534483) Attached to: Ancient Hangover Cure Discovered In Greek Texts

FUCK you and your god damned bullshit.

Fuck you culture warrior identity politics fuckface asshole prick.

BC/AD is part of the fucking culture ass grabbing fuck puke.

FUCK YOU, history changer Goebbels re-writer.

I vote for renaming them BFC ("Before Fucking Christ") and AFD ("Anno Fucking Domini").

Comment: Re:Poor Design... (Score 1) 73

by Guy Harris (#49525901) Attached to: Networking Library Bug Breaks HTTPS In ~1,500 iOS Apps

OS X actually has perfectly fine support for shared libraries. They are supposed to be installed under /Library/Frameworks,

...and OS X keeps track of which installed applications use them, and either prevent uninstallation of shared libraries/frameworks that are used by installed applications or at least warn about it?

No, it doesn't - it doesn't even have an official uninstaller (although the ambitious can whip up a script to do that, such as the Wireshark uninstaller script I have; not sophisticated, though, as it doesn't dump the file list from the package manifest to figure out what stuff needs to be removed, it just has that knowledge wired into it).

And it definitely does not have a way to tie installable application A to installable shared library/framework X, so that installing A automatically installs X if A and X are separate packages from separate vendors.

That is the sort of "[management of] shared libraries/frameworks as installable objects separate from applications that use them" to which I was referring.

And, yes, that does sound a bit like the packaging management systems on some Linux distributions. From my limited experience with various Linux VMs on my Mac, they seems to work OK, but I don't have enough experience with them to say that there aren't problematic failure modes.

At least OS X frameworks have some support for versioning, so that if application A tested with version n of X and set up to require version n and application B is tested with version m of X and set up to require version m, they could be installed "side-by-side".

There's no reason why they couldn't do that on iOS as well, just let developers share frameworks on the App Store and build a mechanism into the App Store where an app can require other apps or frameworks.

And set up a framework (no pun intended) so that they can do the same sort of vetting of frameworks that they do on applications. Yes, that would be a Good Thing, but I'm not about to assume, without further information, that it's not that hard.

Comment: Re:Poor Design... (Score 2) 73

by Guy Harris (#49525741) Attached to: Networking Library Bug Breaks HTTPS In ~1,500 iOS Apps

Non system libraries are statically linked .a files in IOS. Apple insists on this, although I'm not entirely sure why. I guess its to avoid DLL hell.

I suppose they could support providing dynamically-linked libraries as part of an app bundle. However, it's not clear why that would be any better than statically linking the library, as Apple probably wouldn't allow those dynamically-linked libraries to be shared between applications (apps being sandboxed, they couldn't pull in a .dylib from another app bundle) and wouldn't allow them to be updated separately from the app bundle. The only advantages it might provide would be code sharing between executable images in the same app bundle and convenience of building app bundles if the libraries are provided as .dylibs.

Neither OS X nor iOS are really set up to manage shared libraries/frameworks as installable objects separate from applications that use them. Perhaps they should be set up to do so, but that might need to be done carefully to avoid, well, DLL hell.

Comment: Re:Microkernal Boner (Score 1) 229

by Guy Harris (#49495017) Attached to: GNU Hurd 0.6 Released

These days you don't see the same hype around microkernals that you did back then

No, but they are still in use. HURD, FreeBSD, OS X, and iOS all use the Mach microkernel to some extent.

For FreeBSD, presumably you mean "FreeBSD is based on 4.4-Lite, and 4.4BSD picked up the virtual memory system from Mach", rather than "FreeBSD uses the Mach messaging code", which it doesn't. So it doesn't use any of the microkernelish parts of Mach.

(Not that OS X or iOS make much traditionally-microkernelish use of them, either.)

Comment: Re:Microkernal Boner (Score 2) 229

by Guy Harris (#49490707) Attached to: GNU Hurd 0.6 Released

That explains why Windows NT and OS X never got anywhere, considering that one was based on Mach and the other actually uses Mach.

Now, in Windows NT and OS X all the modules ran in the same address space. But they didn't call each other directly. They used the same generic messaging API that modules would from user space, there's just wasn't less overhead in passing the messages. But those examples are ancient history.

Not sure what "modules" you're referring to, but if you're referring to "modules" such as network protocols and file systems in OS X, they most definitely are called directly from the system call layer. Go take a look at the kern , net , and vfs directories of XNU, as well as the netinet directory of XNU and the source to the FAT file system kernel module for examples of code that plugs into the BSD-flavored socket layer and VFS mechanism.

As for the drivers they sit atop, those are called by Boring Old Procedure Calls (and method calls, given that IOKit uses a restricted flavor of C++), not by Mach message passing.

As far as I know, network protocols, file systems, and network and storage device drivers work similarly in NT.

Comment: Re:Should be micro kernel (Score 1) 209

by Guy Harris (#49468299) Attached to: Linux Getting Extensive x86 Assembly Code Refresh

though they have something to do with micokernels

Which isn't that much.

Great, can we agree now that not much is something and not nothing?

Sure, if we'll also agree that "[introducing] (un)loadable modules" to a monolithic kernel "to address maintainability and extendability" does not in the least make that kernel any closer to a microkernel (because, in fact, it doesn't).

In other news Thylacines and Jackals have nothing to do with each other, except they both look like canids and fill similar ecological niches. Apples and oranges . . .

In other other news, Felis catus and Loxodonta africana have nothing to do with each other, except that they have four legs and bear live young.

Srsly, "both are kernels" and "both let you load and unload stuff" isn't much of an ecological niche. True microkernels (not "hybrid kernels" like the NT kernel or XNU) and monolithic kernels (with our without loadable modules) are sufficiently different from one another than "you can add or remove stuff at run time" isn't much in the way of commonality.

Comment: Re:Should be micro kernel (Score 1) 209

by Guy Harris (#49467927) Attached to: Linux Getting Extensive x86 Assembly Code Refresh

I can't find the article now. It was years ago. Perhaps I misunderstood it. But I think it meant something like:

  • Microkernels allow non-fundamental features (such as drivers for hardware that is not connected or not in use) to be loaded and unloaded at will. This is mostly achievable on Linux, through modules.

That's more like "mechanisms X or Y both allow Z to be accomplished"; the only thing that says X and Y have to do with one another is that they both allow Z to be accomplished, which isn't that much.

Comment: Re:Should be micro kernel (Score 4, Insightful) 209

by Guy Harris (#49467757) Attached to: Linux Getting Extensive x86 Assembly Code Refresh

I'm sure you're right, though they have something to do with micokernels. There was Linus interview from a few years back explaining his preference for the monolithic approach, and he explained that modules were introduced to give most of the benefits of the microkernel, without the drawbacks.

I'd have to see that interview to believe that's exactly what he said. In this essay by him, he says

With the 2.0 kernel Linux really grew up a lot. This was the point that we added loadable kernel modules. This obviously improved modularity by making an explicit structure for writing modules. Programmers could work on different modules without risk of interference. I could keep control over what was written into the kernel proper. So once again managing people and managing code led to the same design decision. To keep the number of people working on Linux coordinated, we needed something like kernel modules. But from a design point of view, it was also the right thing to do.

but doesn't at all tie that to microkernels.

Loadable kernel modules in UN*Xes date back at least to SunOS 4.1.3 and AIX 3.0 in the early 1990's. I'm not sure they were introduced to compete with microkernels.

Comment: Re:Speedups? (Score 3, Informative) 209

by Guy Harris (#49467397) Attached to: Linux Getting Extensive x86 Assembly Code Refresh

> There are over 100 separate ... speedups

The last time I looked, which was quite a few years ago TBH, the BSDs have, IIRC, less than 100 lines of x86 assembly, in the bootstrap.

From relatively-recent FreeBSD:

$ find sys/i386 -name '*.[sS]' -print | xargs wc -l
208 sys/i386/acpica/acpi_wakecode.S
40 sys/i386/bios/smapi_bios.S
396 sys/i386/i386/apic_vector.s
78 sys/i386/i386/atpic_vector.s
160 sys/i386/i386/bioscall.s
470 sys/i386/i386/exception.s
900 sys/i386/i386/locore.s
279 sys/i386/i386/mpboot.s
831 sys/i386/i386/support.s
538 sys/i386/i386/swtch.s
179 sys/i386/i386/vm86bios.s
37 sys/i386/linux/linux_locore.s
127 sys/i386/linux/linux_support.s
32 sys/i386/svr4/svr4_locore.s
202 sys/i386/xbox/pic16l.s
494 sys/i386/xen/exception.s
361 sys/i386/xen/locore.s
5332 total
$ find sys/amd64 -name '*.[sS]' -print | xargs wc -l
282 sys/amd64/acpica/acpi_wakecode.S
326 sys/amd64/amd64/apic_vector.S
73 sys/amd64/amd64/atpic_vector.S
541 sys/amd64/amd64/cpu_switch.S
906 sys/amd64/amd64/exception.S
88 sys/amd64/amd64/locore.S
236 sys/amd64/amd64/mpboot.S
56 sys/amd64/amd64/sigtramp.S
732 sys/amd64/amd64/support.S
75 sys/amd64/ia32/ia32_exception.S
161 sys/amd64/ia32/ia32_sigtramp.S
38 sys/amd64/linux32/linux32_locore.s
124 sys/amd64/linux32/linux32_support.s
246 sys/amd64/vmm/intel/vmx_support.S
42 sys/amd64/vmm/vmm_support.S
3926 total

It's about 45,000 lines in Linux 3.19's arch/x86. A fair bit of that is crypto code, presumably either generally hand-optimized or using various new instructions to do various crypto calculations.

Comment: Re:Should be micro kernel (Score 2) 209

by Guy Harris (#49467351) Attached to: Linux Getting Extensive x86 Assembly Code Refresh

As I understand it, NeXT / OSX started with a micro-kernel philosophy and then introduced some monolithic kernel concepts to address the performance bottleneck of messaging between true micro modules.

Meanwhile Linux starts as a monolithic kernel, but introduced (un)loadable modules to address maintainability and extendability.

So if we described it as a continuum with 'pure microkernel' being a '1' and pure monolithic kernel being a '10', then OSX would be something like a '3' and Linux would be a '7'.

Loadable kernel modules have nothing to do with microkernels. A truly micro microkernel wouldn't need loadable kernel modules because all the loadable functionality would run in userland; plenty of monolithic kernels have loadable kernel modules.

And OS X is a lot further from "pure microkernel" than 3. The "monolithic kernel concepts" include "running the networking stack in the kernel, standard BSD-style", "running the file systems in the kernel, standard BSD-style", and "implementing most process and VM management operations with standard system calls in the kernel".

"Hey Ivan, check your six." -- Sidewinder missile jacket patch, showing a Sidewinder driving up the tail of a Russian Su-27

Working...