You want AI that's capable of making good decisions even when the information is incomplete.
The concern isn't about making good decisions, but about the behavior and use of the system's capabilities and emergent properties.
People struggle at memorizing chances, taking shortcuts, computers have exact picture talking into account every single bit.
Memorizing chances isn't very important in no-limit. A rough estimate is all you need because other factors will completely dominate whatever error exists in your estimate. When the implied odds can vary between ~1:1 and 100:1, the second or third digit of your estimate of the chances of making a winning hand (for instance, ~2.5:1 against making a flush) is drowned out.
In car analogy terms, its like worrying about if insurance will cover the broken taillight after your car has been t-boned at an intersection by another car going 60 mph. Yeah, it would be nice if the insurance will replace that taillight... but its more important that they will cover the hospital bills
The NFS mounts were always mounted at boot and not on demand both before and after systemd. The difference was that because there were multiple NFS mounts only proceeded in serial before the switch. After the switch the waiting of the mounts happened in parallel not just with each other but other services too. Yes it is entirely pathological but it really happened (and presumably other parallel inits would have solved it this way too).
For what it's worth I have an EeePC too. The default Xandros distro was a classic case of not running very much because it was highly custom (e.g. no printing, no mdns, kernel doesn't have to probe for all different kinds of hardware, hotplug of USB devices, io scheduler set to deadline etc) and thus was fast - I would always expect it to outperform a generic "full fat" Linux distribution. I'd expect your FreeBSD to beat my current XFCE Ubuntu setup too because I bet you can get start less. With lots of hand tweaks the boot speed to an XFCE desktop on my EeePC 900 is still 17 seconds...
I think he's wrong on this. A computer would still need to consider what his opponent thinks he holds and raise accordingly.
Isn't necessary for chess... the top competitive chess programs (like the foss stockfish...) are not the best suited to beating humans... they still beat humans repeatedly, without mercy, game after game after game. Even the world (human) chess champion (Magnus Carlsen) admits that playing one of these engines is like repeatedly ramming your head into a wall.
The guy that you linked to thinks that knowing how many outs you have is "card counting" -- no. you also apparently think so, which means that you cannot possibly have anything to add on this subject (and your ignorance on this subject is not a secret to you, so why are you pretending?)
Teaching computers to beat humans at bluffing, decoying, and no doubt (now or in time) lying? Is that what we want AI to be capable of? I'm not sure that is a good idea, and the code to do that should never be among the "standard includes". I understand the utility of it in dealing with humans, but still
1) Collect extensive intelligence from phone calls and internet activity of all Americans
2) Don't tell other agencies about it
Anecdote 1: I've just timed a Debian Jessie single CPU hard disk based VM install with BTRFS as the filesystem, a GNOME 3 desktop where the user is auto logged in boot and where an autostart script records the time. Here are my rough systemd and sysvinit results (times are from after the kernel core finished to when the GNOME script ran):
sysvinit (apt-get install sysvinit-core)
First boot: 20 seconds
Second boot: 18 seconds
Third boot: 19 seconds
systemd (apt-get remove sysvinit-core)
First boot: 15 seconds
Second boot: 16 seconds
Third boot: 15 seconds
sysvinit averages 19 seconds, systemd averages 15.33 seconds. In this case it does appear that systemd booted the system faster.
Anecdote 2: Same as above but where the VM's disk is sitting wholly in RAM. Time for sysvinit dropped to 5 seconds and the time for systemd dropped to 4 seconds.
My personal guess is that the more you are running, the slower the disk the more likely systemd is to benefit you. You don't say how you did your comparison though or what type your "disks" were. If your comparison was between different versions of Linux distro then it could simply be that the previous version did less (which is always the fastest way to boot)...
Another anecdote: a few years back I saw Slackware systems at a University converted over to systemd. Boot times (which involved waiting for multiple NFS mounts) went from over three minutes to down to less than a minute because more of the waiting was done in parallel.
On iOS8 third party frameworks can now be dynamically linked (system frameworks could be as well, even before iOS8).
Bookmarking this site for social broadcasting mischief come next April 1st.
"Undressly is a place for people who enjoy undressing to connect."
I think this could be bigger than LinkedIn!