Hacker News new | comments | show | ask | jobs | submit | eps's comments login

Wasn't there a single page PhD thesis that was a single sentence describing a counter-example for some long-standing conjecture?

I realize it's vague (to put it mildly), but it was 20-something years since it came up in the math class in the Uni.

Edit - Haha, found it! It was in Littlewood's Miscellany - Picard's Theorem [1].

[1] https://books.google.ch/books?id=MjVgeT7Laf8C&pg=PA40&lpg=PA...

Because, realistically speaking, there's no notable demand.

Matt, a bug report - http://imgur.com/QMDeGvr

Note where the charge indicator is at.

Yikes. Is that an iPad Pro? If you could share more details that would be great. There's also the issue tracker you may be interested in: https://github.com/hyphen-reader/hyphen/issues

iPad mini, iOS 8.3

Looking at this differently though -

Encryption or not, signs point to meta data collection being absolutely essential to tracking down these pricks' location.

From an earlier discussion https://news.ycombinator.com/item?id=9947749:

> If I understand correctly, this is a framework for non-preemptive cooperative multitasking whereby provided API functions serve as yield points. Pretty much what Windows API was before NT/2000. Not exactly a co-routine library, at least not in a conventional definition of co-routines.

> Yes, that's exactly what it is. Yes, that's exactly what it is. But it also matches wikipedia's difinition of coroutine: "Coroutines are computer program components that generalize subroutines for nonpreemptive multitasking, by allowing multiple entry points for suspending and resuming execution at certain locations."

All coroutine libraries are non-preemptive and cooperative. E.g. in Haskell, threads will switch only on GC allocations. In Go, they only switch on I/O (and maybe function returns). In theory, the compiler could automatically add `yield` statements into non-allocating, non-I/O loops. But nevertheless, all user-space threading is cooperative.

> But nevertheless, all user-space threading is cooperative.

Not necessarily. You can do user-space pre-emptive threading on any system that support pre-emptive signal handlers and that lets you mess around with the stack, particularly if you can generate signals from timers and/or IO operations (both of which you can with POSIX timers)

Then it's not really user-space, is it? You're still paying for a kernel context-switch or two.

It is user-space threading if the scheduler is in user-space.

I disagree. If it's the kernel who's interupting threads, it's not user-space threading. The scheduler just decides which thread gets run next, but the kernel decides when it gets run.

Technically it is not the kernel, it is the hardware clock.

At some point any user space scheduler will switch to the kernel in an event demultiplexing syscall and potentially block there if no user space thread is runnable. By your definition any threading system which doesn't handle all IO purely in user-space can't claim to be user-space threads.

But that is when the userspace must (and wants) to communicate with the kernel. Ultimately, that's the programmer's choice. You could easily write a program in Haskell or Go with two lightweight threads that would keep sending ping/pong messages to each other, and all the waiting (on locks, channels, etc.) and switching would be implemented in userspace.

I don't know enough about userspace/kernelspace communication, maybe I/O (refilling buffers or calling select) and timers are much more lightweight than full thread context switches, but I'm guessing it's still much slower than pure userspace scheduling.

How is a clock signal different? It is just another external event userspace wants to be notified about.

Note that on Unix you can use signals to get IO readiness notification and in fact for sometime on Linux (before epoll) realtime signals were the preferred method to do get notification over a large amount of fds.

Anyway, as a general guideline, user/kernel transition is cheaper than a (kernel) thread/thread transition which is in turn cheaper than a process/process transition.

Agree that coroutines are inherently non-preemptive and cooperative, but not all user-space threading is cooperative.

> conversations around everything from Zombie Cats to Vintage Calculators

Now they are trying to be a Reddit.

Technically, that's an answer to "what you should put in refrigerator."

I had the exact opposite experience with Intel's "steaming pile of crap" as you put it. We had a computationally intensive app that was sped up by 25% compared to the version produced by MS compiler. This was few years ago though.

We used the Intel compiler at my last job and also had some good speedups. But we also ran into a lot of bugs where it would generate non-working code at the higher optimization levels.

For us, the performance was worth the effort of working around the bugs. But that's probably not the case for most projects.

Yep, I could totally see it speeding up computationally intensive code - but try downloading it and using it to compile entire code bases with medium to high level of complexity - like ACE/TAO or Qt or any other OSS project. It might compile at low optimization settings but then it's not faster and the moment you try to use optimizations it makes your life hell.

Getting a recent qt to make clean with any compiler is a pain.

What's sort of problems did you have? I haven't tried since 5.3, but it worked fine just following the directions on the wiki:


... because they didn't cancel unregistered SIMs.

A subtle hint that you can't fuck around with state mass tracking and surveillance needs.


Telcom has always been deeply entwined with state security. It was just easier to ignore this for the past "web 2.0" decade.

"It is difficult to get a man to understand something, when his salary depends on his not understanding it."


Well in this specific case the shit apparently really hit the fan when a high ranking government official was kidnapped and the criminals were using unregistered MTN sims to communicate.

So here we are.


You must be easily amused, and by random false conjectures no less.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact