Ha!

Change is bad!

Nothing good ever comes from it.

Where does this leave Vala? I thought they wanted to make that the default language instead of C.

>He wasn't involved in Quake 3. He was fired after they released Quake 1.

and id hasn't released a decent single player first person shooter since.

Not saying that's due to Romero not being there, but Wolf, Doom, Doom II and Quake I were good games to play as a single player. I really don't feel as if id have bettered them since.

Quake II was not that bad, but everything since ...

What does Bing do?

>Launch background threads to do your resource loading

Which is a great idea, but it would make the job of figuring out how your
main menu on launch would look pretty complicated.

I guess it'd be pretty confusing for most users to have the File->Load menu item to be saying Please Wait while I load shit in the background... instead.

In short, it would complicate the programmer's job, and the user experience *a lot*

Ha! We developers will never learn.

Come Sunday Dec 4th 292,277,026,596AD I bet you there'll still be some poor saps running around doing last minute testing whilst the managers on multi universe conference calls will all be saying :
'but we never thought the cobol code would be going for soo long! We just kept putting off the upgrades, and before you know it 2,922,770,245 centuries had passed and here we are!'

>e.g. no unified kernel event mechanism, unlike *BSD and Solaris

Have to agree, kqueue is a fantastic abstraction & api whereas epoll looks
like a tired 'me too' effort where they got bored halfway through and forget
to support anything but sockets.

Trick you into installing a trojan that then controls your
webcam via a service that periodically makes an outbound connection.

And getting back to the topic, uses Teredo (http://en.wikipedia.org/wiki/Teredo_tunneling) to do the chatting. All on IPV6

>Synchronisation is normally used to provide consistency of the shared resource but not often used to provide overall ordering with regards to accessing it.
>Hence non determinism. If you can't tell which thread gets to access the shared resource and in which order, the program is no longer deterministic.

I am really struggling to imagine a situation where you need to determine ahead of time the order in which a number
of threads need to access a shared resource in.

If the thing needs to be accessed in a specific order, then doesn't it mean that you should just have one thread
operating on that data, since it's by nature a sequential process, no?

The other scenario is where an item might be transitioned to different states as it's changed by, e.g. the result of
some async io (quite a common scenario). But then you use a state engine to ensure that the thing is in a determined
state at all times - and you never care about which thread's going to access it next because every thread should
be capable of moving the item forward to its desired end-state.

>If you can't tell which thread gets to access the shared resource and in which order
If you need to set the order in which threads are accessing a resource, I think somewhere you're doing
it very wrong. But if you have a specific example of where that's necessary I'd love to hear it.

>There's nothing like desperation for creating passion.

I'd say there's nothing like desperation for creating even more desperation.

And then compromises - i.e. take any old shit job just to pay the rent again.
Then you're back at square one.

Have you ever asked for feedback after an unsuccessful interview?

Sometimes interviews are as much about honing your technique as they
are about answering everything 'correctly'. Getting feedback can help you
discover what you can improve to 'suck at interviews' less.

As someone who's done a fair amount of interviewing of candidates, answering questions
correctly is not always what's made a candidate attractive - attitude counts
for a lot. Showing you care about the subject matter, can tackle problems
you've never encountered before with some imagination and have a general
interest in improving your abilities are all things I look for.

Of course, the more interviews you do, the easier it is to get blasé and jaded so I'd say
give yourself a break if it's getting too much.

I have lived in and out of Switzerland, and have seen the effect
of different democracies at work.

On the whole I don't particularly think the Swiss system works
because of the general education level of the populace, after
all they're just people like anybody else with the same impulses
and failings.

But I have noticed that politics are more stable, unlike in the
UK where I come from. There we seem to lurch from idealogical
left to right with too much frequency and minority or more middle
of the road ideas seem to get drowned out.

In Switzerland they seem to have a main goal of competent rule
first and foremost, striking a balance between the desires of all
citizens and the general needs of the country.

In the UK we seem to strive for competent rule where 'competence'
means 'adheres closest to my way of thinking'

What do you mean by 'interact' ?
What do you mean by 'distribute it'?

When you have multi-threaded system then it's usually easy enough to compartment
(or isolate) the data that each thread is working on and provide locking mechanisms to ensure that
where threads do have to share data, they do so in a controlled deterministic fashion.

If they don't , then that's a bug.
Which brings me back to my original point. If it's too complex to understand what's
going on all the time, then you need to reduce complexity. Or get some engineers onboard
that know how to handle concurrency.

In that case you need to get better engineers!

Computer systems should always be exactly deterministic. Since they operate on a very specific
set of instructions (check source code for details), you should *always* be able to determine how they
will act given a specific set of inputs.

If you can't, then you need to drastically reduce the complexity of your systems to a level that these
poor engineers are comfortable with and then work up from that.

Because, at the end of the day (barring hardware glitches), computers do do exactly what they're told to do.
It's not witchcraft.

Yup, loose indentation is a real problem in Python.