Half the country is very concerned with job loss (and for some, increased crime in their neighborhoods).
There, fixed that for you. I (and probably most people) agree that job loss and increased crime are things to be worried about. Attributing both problems to immigration based on no credible data is not the way to solve those problems, though. It may not be overtly racist, but it is fear without fact.
Why is it in any way surprising he had a strong base?
He won because he is a good cheerleader, and masterful at controlling his message. Probably better than Obama was during the 2008 election. That doesn't mean his policy ideas make sense, are not contradictory, or will ever actually be effective. In the same vein, Obama may have been a good orator, but he (rightfully) gets a lot of criticism from both the right and left for being a fairly ineffectual President.
Apparently they are banning electronic devices in the cabin due to the possibility of concealing explosives in them in "a way that is hard to detect". Ok, let's assume that is true. Question from me is, what difference does it make if it is in carry-on or checked baggage? Once it is on the plane, wouldn't an attacker be able to detonate it remotely if it is in checked baggage? Am I missing something here?
Scientists Successfully Decode the Genome of Quinoa
Ugh. I know this is a primarily a tech site, but why can't we make more of an effort to use the actual scientific terms instead meaningless stupid phrases. It's kind of like saying "Company develops new method to talk to computers" instead of "Company develops new programming language, Rust"
"Scientists sequence and assemble the genome of Chenopodium quinoa (aka "quinoa")"
There, much better. Heck, that's lifted almost word-for-word from the actual scientific article, so it's not like it requires a ton of effort.
Breeding doesn't modify genes. You cannot breed two animals together or cross pollinate two plants and get arbitrary genes that weren't there to begin with.
Of course it does. I suggest you take a college-level Biology course and learn a little bit about mechanisms of genetic variation before saying things like:
The fact that you don't know that pretty much disqualifies you from any discussion here as you're not fooling anybody.
Those alterations have to already exist in order for breeding to get anywhere.
No, they don't. The process is just slower for non-GMO breeding. Random mutations can cause the plant to produce new chemicals that may or may not be harmful. In one case, you end up with oranges becoming blood oranges, in another you end up with a potato with way too much solanine.
Just to add to this. Humans may have accelerated the process of cross-Kingdom genetic variation by bringing organisms from very different geography and ecological context together, but that doesn't make it "unnatural." Breeding is also an acceleration of a natural process, unless you think hundreds of varieties of corn all grow in neatly ordered rows to facilitate cross-pollination in the wild.
You may have learned in your high school biology class that sexual reproduction is the only or primary method of introducing genetic variation within a species, but it really isn't. Genetic variation very frequently comes from other sources. It is no accident (or malfeasance) that one of the methods for introducing genetic modifications into plants uses a bacterium (Agrobacterium) or, for that matter, that naturally-occurring human viruses are frequently used to introduce mutations into human tissue-culture cell lines. Microbes are ancient and everywhere, and they are responsible for a lot of cross-Kingdom genetic exchange.
That's because you are letting the rules of nature determine the outcome.
Guess what? Genetic engineering is also subject to "the rules of nature" to "determine the outcome." It is not some magic wand that suddenly results in a new organism. The rules that determine whether particular genetic modifications are lethal (to the plant) or effective (change the phenotype), and whether effective modifications are "safe" (do not result in phenotypic changes that are toxic to humans) or not, are a complex system of interacting regulatory networks. How the DNA modification takes place is irrelevant to the outcome. It is foolish to assume that random genetic variation followed by selection (aka "breeding") is any safer or more controlled than directed and specific modifications to the genome. Is is also foolish to assume that the "safeness" of any phenotypic change to an organism is context-independent or immutable. See, for example, the increasing prevalence of type II diabetes, which is only now leading to concerns over past breeding-practices that produced then-desirable sweeter-tasting (ie: more sugar) and easier-to-digest (ie: less fiber) varieties of common staples (rice, wheat, corn, etc).
We have complex financial models that are coded in C# for production use but which also exist in spreadsheets for the purposes of documentation and independent model validation.
You might want to have a look at RMarkdown (http://rmarkdown.rstudio.com/index.html). It's pretty much designed for exactly that purpose. You get to use the very nice R framework, and be able to very naturally document changes to your models. You can use revision control if you want to. You can even embed interactive widgets if you want to go that far. This guy (http://vnijs.github.io/radiant/) wrote a business intelligence platform on top of R using Shiny. There is lots of cool stuff to do here. More importantly, you get to take advantage of a lot of very robust statistical models, a very active development community, and proper data management support (ex: relational databases). R project files are just text files, so it's pretty easy to archive and version control using whichever tools you have for those purposes.
No the point of the article was "questions whether more information is the same thing as more understanding."
No, that was not the point of the article at all. The point of the article was that there is an implicit assumption in the field that we just lack sufficient data. That the methodologies used to analyze that data are fine, but because we don't have enough data, we fail to successfully understand cognition. The authors argue that, no, there is not enough but data, but also that the methodologies are flawed; that the methodologies themselves need to be validated. But because we don't have a ground truth with which to study the brain, we have no way of validating on that data set.
So they are looking for a suitable stand-in, to validate the methodology. That is all. It is not their intention to learn anything about the brain from the microprocessor, just to replicate the known ground truth of the microprocessor using the "reverse-engineering" methods that are common and accepted in the neuroscience field to determine whether they are adequate.
No, they argue that the 6502 (or just a microprocessor) is an acceptable model for validating the approaches used in neuroscience to analyze complex data sets, which is exactly what I said in my comment above. In other words, if they can successfully determine the ground truth of the microprocessor using those approaches and with limited a priori knowledge, then the methodologies have potential. Otherwise, they need to be refined until they are able to do this. Validating against an imperfect model is better than having no validation at all.
More to the point: "Gaël Varoquaux, a machine-learning specialist at the Institute for Research in Computer Science and Automation, in France, says that the 6502 in particular is about as different from a brain as it could be."
I suggest you read the actual scientific article and not just the Economist summary blurb. It is open access.
But that logic only makes sense if microprocessors and brains were similar enough that comparable methods could be used to attempt to understand them. But that isn't true.
Actually, they are arguing that it is true. From the article,
"Obviously the brain is not a processor, and a tremendous amount of effort and time have been spent characterizing these differences over the past century [22, 23, 59]. Neural systems are analog and and biophysically complex, they operate at temporal scales vastly slower than this classical processor but with far greater parallelism than is available in state of the art processors. Typical neurons also have several orders of magnitude more inputs than a transistor. Moreover, the design process for the brain (evolution) is dramatically different from that of the processor (the MOS6502 was designed by a small team of people over a few years). As such, we should be skeptical about generalizing from processors to the brain.
"However, we cannot write off the failure of the methods we used on the processor simply because processors are different from neural systems. After all, the brain also consists of a large number of modules that can equally switch their input and output properties. It also has prominent oscillations, which may act as clock signals as well [60]. Similarly, a small number of relevant connections can produce drivers that are more important than those of the bulk of the activity. Also, the localization of function that is often assumed to simplify models of the brain is only a very rough approximation. This is true even in an area like V1 where a great diversity of co-localized cells can be found [61]. Altogether, there seems to be little reason to assume that any of the methods we used should be more meaningful on brains than on the processor."
It is a really interesting exercise because it highlights a critically important problem in the field of neuroscience: we don't know the ground truth, so analyses of complex data sets cannot be validated. There is no way to know if the methodologies being used are actually effectual. Is a microprocessor the best model system? Probably not. But it is something to start with. If we can validate successfully on that, we have a better chance of succeeding on the brain.
This may stem from a lack of awareness on the part of website designers or from the difficulty in a content-management system (CMS) getting the curl direction correct every time.
LaTeX solved this problem a long time ago. `` = “ '' = ”
Any CMS should easily be able to make these substitutions as well. For the people commenting about code samples and not wanting smart quotes around their literal strings, this solves that problem as well. For code samples, use "" instead of ``''. Problem solved. Not sure why this is so difficult...
As for what starts and stops at each runlevel, that's as easy as an "ls". Beats grepping a myriad of MSDOS ini files
Agreed that it isn't quite as nice and easy as an "ls",
Scratch that. It is as easy as an "ls". I was poking around in the/etc/systemd directory and realized/etc/systemd/system is functionally equivalent to/etc/rcX.d/. It is maintained by the systemd daemon, but it consists of a bunch of symlinks to service unit files that allow you to very quickly and easily see which services are dependencies of a particular target.
So if I update any of the libraries that init uses, all I have to do is a "telinit q"?
systemctl daemon-reexec
That one isn't mapped to a telinit equivalent (I don't think).
Last I checked, that was broken in upstart
Lots of things were broken in upstart. Systemd is a tremendous improvement over upstart, much to the chagrin of Mark Shuttleworth.
And systemd now lets me drop to single user mode? That's an improvement.
That's been there, for a while. I'm not sure who these "perps" are that you speak of, but systemd will do anything you tell it to. If you want a single user mode, define a target that creates a single user mode, just like you would define runlevel 1 to not start multiple ttys. I didn't follow every development of systemd as it was happening, and only really jumped in when it came (officially) to Red Hat 7.2 and then Ubuntu 16.04. While there are some lingering integration issues still (mostly with specific daemons), I would say it works pretty well, and the distro maintainers have done a lot good work with backwards-compatibility scripts to help people transition from sysvinit. So yes, there is a rescue.target, which is also called runlevel1.target on both Fedora and Debian.
One of the absolute worst features of systemd (and inittab when abused) is automatic restart.
I never said anything about automatic restart. Systemd allows you to be alerted to and to respond to process failures. To me, that's predictability. If I start a bunch of network services and one of them fails, systemd will decide whether to continue (ie: the dependency tree allows it) or to fail. Regardless, the outcome is entirely predictable. Services that depend on other services (which includes the target state itself) will have all of their dependencies satisfied, or they won't be started, and anything that fails will be logged in a consistent manner that is easily parseable by a system monitoring utility. When you "telinit 3", sysvinit runs all of the scripts in/etc/rc3.d and if they start they start, if they fail they fail. It's up to you to scrape the logs and keep tabs on all of the daemons. The state "runlevel 3" is not guaranteed.
Because the start order is 100% predictable.
Ah, ok, that's a different kind of predictable. I agree, start order is not predictable with systemd. I would argue, though, that it doesn't need to be because you have explicit dependencies that allow depending on the actual started and functioning state of a prior process (as opposed to just a numbering scheme), and logged events that allow you to determine precisely when and where (and often why) a dependency tree failed. You don't need to step through the boot process one script at a time because the log tells you exactly what failed, and you can start your debugging there right at that point.
As for what starts and stops at each runlevel, that's as easy as an "ls". Beats grepping a myriad of MSDOS ini files
Agreed that it isn't quite as nice and easy as an "ls", but it definitely is not as complicated as grepping the unit files and trying to figure out when things start. The nice thing about explicitly declaring your dependencies is that you can have systemd show them to you. Let it do the work so you don't have to.
And I find it to combine the worst aspects of Windows 95.ini files
That's kind of funny because.ini files were one of the better parts of Win95. They were simple text, easy to read and edit (by a human) configuration files, that happened to use [bracketed] headers, but whatever. Samba actually uses that convention for smb.conf, by the way. Anyway, Win became much worse when they took away the.ini files and replaced them with the registry. If I need to change a configuration, I would rather do it in a plain non-executable text file, rather than something structured but cumbersome like XML, or something with variables and conditionals built-in but takes time to parse and study like a shell script.
Of course you can change targets ("runlevels") with systemd without rebooting. If you use Fedora, they have even preserved the telinit command and made equivalent "runlevel" targets, to make it easy for people coming from a sysvinit background.
I like good old-fashioned runlevels, and not named abstractions that may differ from system to system
Um, why do you think "old-fashioned" runlevels are any less abstract than named process groups. A runlevel is just a group of processes to start that happens to be named as a number (ex: runlevel 3 could just as easily be "network-enabled" and function identically). The fact that most linux distributions used runlevels may have been a convention, but it was hardly a standard. In fact, Red Hat famously used runlevel 5 to distinguish between an X and console environment, whereas Debian used runlevel 3 to distinguish between single-user vs multi-user environment regardless of whether there was a desktop session manager running. So I would definitely call runlevels "named abstractions that may differ from system to system". Since derivative distributions (ex: Ubuntu from Debian and Mandrake from Red Hat) tended to adopt the original's runlevel classification, it may have given the appearance that there was a de facto standard, but there really wasn't.
Predictability is good.
Correct. Which includes knowing that your processes actually started and not just that you told them to start, but maybe they failed, when you change runlevels.
So are posix scripts, which continue working even on systems where/bin/sh is lightweight ash or some other bourne family shell that isn't bash.
Some do, some don't. It depends on who wrote the script. When Ubuntu switched to dash, which was one of the first attempts to speed up boot times years ago, quite a few of the boot scripts broke and had to be rewritten. If you upgraded Ubuntu and suddenly one of your services didn't start, switching back to bash was usually the easiest fix. They eventually ironed out all of the bugs, but it was shaky for a while.
So they are only "roughly equivalent" if by that you mean "within 10 orders of magnitude of each other".
I think you meant "one IPv4 Internet (4.3 billion hosts) where each host NATs an entire IPv4 internet vs. one IPv6/64 prefix (4.3 billion IPv4 Internets) are exactly equivalent".
In practice you can't assign anything smaller than a/64 -- snip -- It's still way more address space than we'll ever reasonably need, but not quite as ridiculous as it looks at first glance.
While true, you will get that/64 assigned to you within a/64 prefix. In other words, there are 18 billion billion prefixes each with 18 billion billion addresses, so it really is as ridiculous as it looks at first glance. Not complaining, though....
This is why some 3rd world countries won't use it, not fear of GMO itself, but they don't want to be beholden to an American company for their seeds.
Hardly. Most developing countries want to use GM crops (read: farmers want to use it, but government forbids it), but the countries they export to, like Germany, are poised to instantly block all imports if they allow GM crops to be used. Seriously, it really is that crazy. Needing to buy seed from somewhere is the least of their concerns.
When you are talking about GM the technology and whether it should be used, safety is the only consideration that matters, because that is the only unknown (that and effectiveness). Every other consideration is concerned with the industry of agriculture itself and has nothing to do with GM directly.
I have two objections to GM crops: biodiversity and lock-in
Biodiversity was a concern long before GM crops were on the scene. Any kind of controlled breeding and selection of popular varieties (driven by the free market) can create problems with biodiversity. Cavendish bananas are not genetically-modified, and yet they are by far the most widely used cultivar globally. Lock-in is a more valid concern, although the recent Supreme Court decision on the patentability of genes may make it less so. If seed companies can only patent the seeds, but not the actual genetic modifications, it would be the same situation as currently exists with patentable crop varieties where there is plenty of room for free market competition. Of course, the government could also refuse to recognize any patents on food crops. Either way, it is a regulatory problem, not a technology problem.
It's not really the version of the library that's the problem, in the majority of cases. As a few have already mentioned, the interfaces often don't change between library versions, so older software can often compile fine against newer libraries. The problem is, most people want binary distributions. Source distributions are great, and very flexible, until you want to A) install something closed-source, or B) install something large and complex, like LibreOffice. Most people, myself included, don't care to sit around and wait for 2-3 hrs for something to compile just so they can get some work done. If you can just install it, you are usually much happier.
The problem is, to get binaries to share dependencies, it is not just the filenames and locations that must be same. The symbol tables have to be exactly what the app is looking for (ie: linked against). So that means, the build environment has to be the same, or at least generic enough, to get the required compatibility. If you change something like glibc, everything compiled against it has to be recompiled and relinked. That is the major source of frustration, and it is not an easy problem to solve.
Not really. Deb and rpm can handle multiple versions just fine, as long as the underlying software supports multiple versions. Remember, a package is just a collection of files with some instructions where to put them. So if you try to install two files with the same name in one place, you are going to have problems. In other words, it's not the versioning, it's the inherent limitation of the filesystem itself. If a library renames itself between versions, though, it won't have problems. Very few libraries go to the trouble to do that, though.
Interesting. That's more information than I was able to find anywhere else. Thanks.
Here's what I'm most worried about, though. How dependent is it on non-lazy packagers? In other words, the easiest and most convenient way to package anything is to ship with all dependencies and the app uses those. The problem, though, is each application is then solely responsible for updating itself, including to patch bugs in any dependencies, so it quickly leads to running a million app updaters in the background, which is the current nightmare on Windows and OS X. Ideally, this system would be smart enough to use the base system by default and only use the supplied dependency if the base system can't provide it or if there is a conflict of some sort. But I doubt it will do that, which means it is on the packagers to check the base system first before installing their own dependencies. Somehow I doubt they are going to do that, though.
g. RPM dependencies are calculated from files and SONAMEs, but can also be specified manually by the packager, including version inequalities of other packages.
Debian has this too, and I think it is actually a good deal more flexible than rpm, at least from what I remember from my brief stint with Red Hat back in the day. There's a reason Debian was able to have apt long before Red Hat/Fedora had yum.
Well, then that's really a problem with the community not enforcing proper requirement standards that reflect reality on important packages.
This is the real problem. And I dare say it is 99% an Ubuntu problem because they really like to break everything with each subsequent release. Debian has been a rolling release distribution since forever and is renown for the incredible robustness with which packages can be shared between stable, testing, and even unstable, as well as the ease of transitioning from one to the other (ex: when testing becomes the new stable). And they have once or twice had to do some massive renaming of library dependencies, but managed without a hiccup, which is a testament to the quality of the deb system.
No, the problem is Ubuntu. Their versioning is a constant clusterfsck of broken, incompatible package naming. And they heavily abuse "virtual" packages for their own purposes which leads to the breakage in Samba like the GP described. It is horrible release management and is one of the many things wrong with Ubuntu. However, Ubuntu manages to stay more up-to-date, and has some pretty nifty userland tools, so I find myself using it much more than Debian. But I lament every time I have to upgrade, or if I want to move packages between versions.
Snap sounds like a system with some much-needed features, but what I would really like is for those features to be integrated into deb. Unfortunately, Ubuntu is following their usual pattern of aloofness. Both Debian and Ubuntu would benefit tremendously if they could work together to enhance deb. Transactional updates? Who doesn't want that? That is a great feature. But nope, that's not going to happen, apparently. We're going to end up with another Mir, or Upstart, or Compiz (shudder).
The details on this new packaging system are scarce--and I've checked--but it looks like a reimplementation of Docker,
I guess we'll find out more in time, because I too couldn't find any details on how this is implemented. If it does use containers (a la Docker), that would be really cool. As soon as Docker started getting more fleshed out, this was the first application I thought of that would be perfect for it.
An application being able to use alternative libraries is definitely a need on modern linux. I can't count the number of times that I needed to do massive upgrades of the system just to install a newer version of an app I was using. My only worry is that this will depend on the non-laziness of app developers to work well. Snap packages can use the underlying system, but only if app developers take the time to specify their dependencies, which is something they already don't want to do, apparently. So instead, they bundle their own libraries, even if they are already available on the system, and we get OSX bundles, which I'm not a big fan of. Ideally the snap system would default to using a system library if it meets a dependency and only a bundled library if that dependency is not met, but based on the scarce information available that doesn't seem to be the case.
It would also be nice if there was a quick way to determine library versions in all installed snaps, so that you can see which might be vulnerable to recent security errata, for example. Not sure if they have plans for tools like that, but it would sure be useful.
Slashdot Mirror
Half the country is very concerned with job loss (and for some, increased crime in their neighborhoods).
There, fixed that for you. I (and probably most people) agree that job loss and increased crime are things to be worried about. Attributing both problems to immigration based on no credible data is not the way to solve those problems, though. It may not be overtly racist, but it is fear without fact.
Why is it in any way surprising he had a strong base?
He won because he is a good cheerleader, and masterful at controlling his message. Probably better than Obama was during the 2008 election. That doesn't mean his policy ideas make sense, are not contradictory, or will ever actually be effective. In the same vein, Obama may have been a good orator, but he (rightfully) gets a lot of criticism from both the right and left for being a fairly ineffectual President.
So, I read one news article here,
https://www.nytimes.com/2017/0...
Apparently they are banning electronic devices in the cabin due to the possibility of concealing explosives in them in "a way that is hard to detect". Ok, let's assume that is true. Question from me is, what difference does it make if it is in carry-on or checked baggage? Once it is on the plane, wouldn't an attacker be able to detonate it remotely if it is in checked baggage? Am I missing something here?
Scientists Successfully Decode the Genome of Quinoa
Ugh. I know this is a primarily a tech site, but why can't we make more of an effort to use the actual scientific terms instead meaningless stupid phrases.
It's kind of like saying "Company develops new method to talk to computers" instead of "Company develops new programming language, Rust"
"Scientists sequence and assemble the genome of Chenopodium quinoa (aka "quinoa")"
There, much better. Heck, that's lifted almost word-for-word from the actual scientific article, so it's not like it requires a ton of effort.
Breeding doesn't modify genes. You cannot breed two animals together or cross pollinate two plants and get arbitrary genes that weren't there to begin with.
Of course it does. I suggest you take a college-level Biology course and learn a little bit about mechanisms of genetic variation before saying things like:
The fact that you don't know that pretty much disqualifies you from any discussion here as you're not fooling anybody.
Those alterations have to already exist in order for breeding to get anywhere.
No, they don't. The process is just slower for non-GMO breeding. Random mutations can cause the plant to produce new chemicals that may or may not be harmful. In one case, you end up with oranges becoming blood oranges, in another you end up with a potato with way too much solanine.
Just to add to this. Humans may have accelerated the process of cross-Kingdom genetic variation by bringing organisms from very different geography and ecological context together, but that doesn't make it "unnatural." Breeding is also an acceleration of a natural process, unless you think hundreds of varieties of corn all grow in neatly ordered rows to facilitate cross-pollination in the wild.
You may have learned in your high school biology class that sexual reproduction is the only or primary method of introducing genetic variation within a species, but it really isn't. Genetic variation very frequently comes from other sources. It is no accident (or malfeasance) that one of the methods for introducing genetic modifications into plants uses a bacterium (Agrobacterium) or, for that matter, that naturally-occurring human viruses are frequently used to introduce mutations into human tissue-culture cell lines. Microbes are ancient and everywhere, and they are responsible for a lot of cross-Kingdom genetic exchange.
That's because you are letting the rules of nature determine the outcome.
Guess what? Genetic engineering is also subject to "the rules of nature" to "determine the outcome." It is not some magic wand that suddenly results in a new organism. The rules that determine whether particular genetic modifications are lethal (to the plant) or effective (change the phenotype), and whether effective modifications are "safe" (do not result in phenotypic changes that are toxic to humans) or not, are a complex system of interacting regulatory networks. How the DNA modification takes place is irrelevant to the outcome. It is foolish to assume that random genetic variation followed by selection (aka "breeding") is any safer or more controlled than directed and specific modifications to the genome. Is is also foolish to assume that the "safeness" of any phenotypic change to an organism is context-independent or immutable. See, for example, the increasing prevalence of type II diabetes, which is only now leading to concerns over past breeding-practices that produced then-desirable sweeter-tasting (ie: more sugar) and easier-to-digest (ie: less fiber) varieties of common staples (rice, wheat, corn, etc).
We have complex financial models that are coded in C# for production use but which also exist in spreadsheets for the purposes of documentation and independent model validation.
You might want to have a look at RMarkdown (http://rmarkdown.rstudio.com/index.html). It's pretty much designed for exactly that purpose. You get to use the very nice R framework, and be able to very naturally document changes to your models. You can use revision control if you want to. You can even embed interactive widgets if you want to go that far. This guy (http://vnijs.github.io/radiant/) wrote a business intelligence platform on top of R using Shiny. There is lots of cool stuff to do here. More importantly, you get to take advantage of a lot of very robust statistical models, a very active development community, and proper data management support (ex: relational databases). R project files are just text files, so it's pretty easy to archive and version control using whichever tools you have for those purposes.
No the point of the article was "questions whether more information is the same thing as more understanding."
No, that was not the point of the article at all. The point of the article was that there is an implicit assumption in the field that we just lack sufficient data. That the methodologies used to analyze that data are fine, but because we don't have enough data, we fail to successfully understand cognition. The authors argue that, no, there is not enough but data, but also that the methodologies are flawed; that the methodologies themselves need to be validated. But because we don't have a ground truth with which to study the brain, we have no way of validating on that data set.
So they are looking for a suitable stand-in, to validate the methodology. That is all. It is not their intention to learn anything about the brain from the microprocessor, just to replicate the known ground truth of the microprocessor using the "reverse-engineering" methods that are common and accepted in the neuroscience field to determine whether they are adequate.
No, they argue that the 6502 (or just a microprocessor) is an acceptable model for validating the approaches used in neuroscience to analyze complex data sets, which is exactly what I said in my comment above. In other words, if they can successfully determine the ground truth of the microprocessor using those approaches and with limited a priori knowledge, then the methodologies have potential. Otherwise, they need to be refined until they are able to do this. Validating against an imperfect model is better than having no validation at all.
More to the point: "Gaël Varoquaux, a machine-learning specialist at the Institute for Research in Computer Science and Automation, in France, says that the 6502 in particular is about as different from a brain as it could be."
I suggest you read the actual scientific article and not just the Economist summary blurb. It is open access.
But that logic only makes sense if microprocessors and brains were similar enough that comparable methods could be used to attempt to understand them. But that isn't true.
Actually, they are arguing that it is true. From the article,
"Obviously the brain is not a processor, and a tremendous amount of effort and time have been spent characterizing these differences over the past century [22, 23, 59]. Neural systems are analog and and biophysically complex, they operate at temporal scales vastly slower than this classical processor but with far greater parallelism than is available in state of the art processors. Typical neurons also have several orders of magnitude more inputs than a transistor. Moreover, the design process for the brain (evolution) is dramatically different from that of the processor (the MOS6502 was designed by a small team of people over a few years). As such, we should be skeptical about generalizing from processors to the brain.
"However, we cannot write off the failure of the methods we used on the processor simply because processors are different from neural systems. After all, the brain also consists of a large number of modules that can equally switch their input and output properties. It also has prominent oscillations, which may act as clock signals as well [60]. Similarly, a small number of relevant connections can produce drivers that are more important than those of the bulk of the activity. Also, the localization of function that is often assumed to simplify models of the brain is only a very rough approximation. This is true even in an area like V1 where a great diversity of co-localized cells can be found [61]. Altogether, there seems to be little reason to assume that any of the methods we used should be more meaningful on brains than on the processor."
It is a really interesting exercise because it highlights a critically important problem in the field of neuroscience: we don't know the ground truth, so analyses of complex data sets cannot be validated. There is no way to know if the methodologies being used are actually effectual. Is a microprocessor the best model system? Probably not. But it is something to start with. If we can validate successfully on that, we have a better chance of succeeding on the brain.
This may stem from a lack of awareness on the part of website designers or from the difficulty in a content-management system (CMS) getting the curl direction correct every time.
LaTeX solved this problem a long time ago.
`` = “
'' = ”
Any CMS should easily be able to make these substitutions as well. For the people commenting about code samples and not wanting smart quotes around their literal strings, this solves that problem as well. For code samples, use "" instead of ``''. Problem solved. Not sure why this is so difficult...
As for what starts and stops at each runlevel, that's as easy as an "ls". Beats grepping a myriad of MSDOS ini files
Agreed that it isn't quite as nice and easy as an "ls",
Scratch that. It is as easy as an "ls". I was poking around in the /etc/systemd directory and realized /etc/systemd/system is functionally equivalent to /etc/rcX.d/. It is maintained by the systemd daemon, but it consists of a bunch of symlinks to service unit files that allow you to very quickly and easily see which services are dependencies of a particular target.
So if I update any of the libraries that init uses, all I have to do is a "telinit q"?
systemctl daemon-reexec
That one isn't mapped to a telinit equivalent (I don't think).
Last I checked, that was broken in upstart
Lots of things were broken in upstart. Systemd is a tremendous improvement over upstart, much to the chagrin of Mark Shuttleworth.
And systemd now lets me drop to single user mode? That's an improvement.
That's been there, for a while. I'm not sure who these "perps" are that you speak of, but systemd will do anything you tell it to. If you want a single user mode, define a target that creates a single user mode, just like you would define runlevel 1 to not start multiple ttys. I didn't follow every development of systemd as it was happening, and only really jumped in when it came (officially) to Red Hat 7.2 and then Ubuntu 16.04. While there are some lingering integration issues still (mostly with specific daemons), I would say it works pretty well, and the distro maintainers have done a lot good work with backwards-compatibility scripts to help people transition from sysvinit. So yes, there is a rescue.target, which is also called runlevel1.target on both Fedora and Debian.
One of the absolute worst features of systemd (and inittab when abused) is automatic restart.
I never said anything about automatic restart. Systemd allows you to be alerted to and to respond to process failures. To me, that's predictability. If I start a bunch of network services and one of them fails, systemd will decide whether to continue (ie: the dependency tree allows it) or to fail. Regardless, the outcome is entirely predictable. Services that depend on other services (which includes the target state itself) will have all of their dependencies satisfied, or they won't be started, and anything that fails will be logged in a consistent manner that is easily parseable by a system monitoring utility. When you "telinit 3", sysvinit runs all of the scripts in /etc/rc3.d and if they start they start, if they fail they fail. It's up to you to scrape the logs and keep tabs on all of the daemons. The state "runlevel 3" is not guaranteed.
Because the start order is 100% predictable.
Ah, ok, that's a different kind of predictable. I agree, start order is not predictable with systemd. I would argue, though, that it doesn't need to be because you have explicit dependencies that allow depending on the actual started and functioning state of a prior process (as opposed to just a numbering scheme), and logged events that allow you to determine precisely when and where (and often why) a dependency tree failed. You don't need to step through the boot process one script at a time because the log tells you exactly what failed, and you can start your debugging there right at that point.
As for what starts and stops at each runlevel, that's as easy as an "ls". Beats grepping a myriad of MSDOS ini files
Agreed that it isn't quite as nice and easy as an "ls", but it definitely is not as complicated as grepping the unit files and trying to figure out when things start. The nice thing about explicitly declaring your dependencies is that you can have systemd show them to you. Let it do the work so you don't have to.
And I find it to combine the worst aspects of Windows 95 .ini files
That's kind of funny because .ini files were one of the better parts of Win95. They were simple text, easy to read and edit (by a human) configuration files, that happened to use [bracketed] headers, but whatever. Samba actually uses that convention for smb.conf, by the way. Anyway, Win became much worse when they took away the .ini files and replaced them with the registry. If I need to change a configuration, I would rather do it in a plain non-executable text file, rather than something structured but cumbersome like XML, or something with variables and conditionals built-in but takes time to parse and study like a shell script.
Of course you can change targets ("runlevels") with systemd without rebooting. If you use Fedora, they have even preserved the telinit command and made equivalent "runlevel" targets, to make it easy for people coming from a sysvinit background.
https://fedoraproject.org/wiki...
I like good old-fashioned runlevels, and not named abstractions that may differ from system to system
Um, why do you think "old-fashioned" runlevels are any less abstract than named process groups. A runlevel is just a group of processes to start that happens to be named as a number (ex: runlevel 3 could just as easily be "network-enabled" and function identically). The fact that most linux distributions used runlevels may have been a convention, but it was hardly a standard. In fact, Red Hat famously used runlevel 5 to distinguish between an X and console environment, whereas Debian used runlevel 3 to distinguish between single-user vs multi-user environment regardless of whether there was a desktop session manager running. So I would definitely call runlevels "named abstractions that may differ from system to system". Since derivative distributions (ex: Ubuntu from Debian and Mandrake from Red Hat) tended to adopt the original's runlevel classification, it may have given the appearance that there was a de facto standard, but there really wasn't.
Predictability is good.
Correct. Which includes knowing that your processes actually started and not just that you told them to start, but maybe they failed, when you change runlevels.
So are posix scripts, which continue working even on systems where /bin/sh is lightweight ash or some other bourne family shell that isn't bash.
Some do, some don't. It depends on who wrote the script. When Ubuntu switched to dash, which was one of the first attempts to speed up boot times years ago, quite a few of the boot scripts broke and had to be rewritten. If you upgraded Ubuntu and suddenly one of your services didn't start, switching back to bash was usually the easiest fix. They eventually ironed out all of the bugs, but it was shaky for a while.
1 IPv4 address hosting a subnet with NAT vs. an IPv6 /64 prefix are roughly equivalent
Uhhh....
2^32 = ~4.3 billion
2^64 = ~18 billion billion
So they are only "roughly equivalent" if by that you mean "within 10 orders of magnitude of each other".
I think you meant "one IPv4 Internet (4.3 billion hosts) where each host NATs an entire IPv4 internet vs. one IPv6 /64 prefix (4.3 billion IPv4 Internets) are exactly equivalent".
In practice you can't assign anything smaller than a /64
-- snip --
It's still way more address space than we'll ever reasonably need, but not quite as ridiculous as it looks at first glance.
While true, you will get that /64 assigned to you within a /64 prefix. In other words, there are 18 billion billion prefixes each with 18 billion billion addresses, so it really is as ridiculous as it looks at first glance. Not complaining, though....
This is why some 3rd world countries won't use it, not fear of GMO itself, but they don't want to be beholden to an American company for their seeds.
Hardly. Most developing countries want to use GM crops (read: farmers want to use it, but government forbids it), but the countries they export to, like Germany, are poised to instantly block all imports if they allow GM crops to be used. Seriously, it really is that crazy. Needing to buy seed from somewhere is the least of their concerns.
Safety is a red herring.
When you are talking about GM the technology and whether it should be used, safety is the only consideration that matters, because that is the only unknown (that and effectiveness). Every other consideration is concerned with the industry of agriculture itself and has nothing to do with GM directly.
I have two objections to GM crops: biodiversity and lock-in
Biodiversity was a concern long before GM crops were on the scene. Any kind of controlled breeding and selection of popular varieties (driven by the free market) can create problems with biodiversity. Cavendish bananas are not genetically-modified, and yet they are by far the most widely used cultivar globally. Lock-in is a more valid concern, although the recent Supreme Court decision on the patentability of genes may make it less so. If seed companies can only patent the seeds, but not the actual genetic modifications, it would be the same situation as currently exists with patentable crop varieties where there is plenty of room for free market competition. Of course, the government could also refuse to recognize any patents on food crops. Either way, it is a regulatory problem, not a technology problem.
It's not really the version of the library that's the problem, in the majority of cases. As a few have already mentioned, the interfaces often don't change between library versions, so older software can often compile fine against newer libraries. The problem is, most people want binary distributions. Source distributions are great, and very flexible, until you want to A) install something closed-source, or B) install something large and complex, like LibreOffice. Most people, myself included, don't care to sit around and wait for 2-3 hrs for something to compile just so they can get some work done. If you can just install it, you are usually much happier.
The problem is, to get binaries to share dependencies, it is not just the filenames and locations that must be same. The symbol tables have to be exactly what the app is looking for (ie: linked against). So that means, the build environment has to be the same, or at least generic enough, to get the required compatibility. If you change something like glibc, everything compiled against it has to be recompiled and relinked. That is the major source of frustration, and it is not an easy problem to solve.
Not really. Deb and rpm can handle multiple versions just fine, as long as the underlying software supports multiple versions. Remember, a package is just a collection of files with some instructions where to put them. So if you try to install two files with the same name in one place, you are going to have problems. In other words, it's not the versioning, it's the inherent limitation of the filesystem itself. If a library renames itself between versions, though, it won't have problems. Very few libraries go to the trouble to do that, though.
Interesting. That's more information than I was able to find anywhere else. Thanks.
Here's what I'm most worried about, though. How dependent is it on non-lazy packagers? In other words, the easiest and most convenient way to package anything is to ship with all dependencies and the app uses those. The problem, though, is each application is then solely responsible for updating itself, including to patch bugs in any dependencies, so it quickly leads to running a million app updaters in the background, which is the current nightmare on Windows and OS X. Ideally, this system would be smart enough to use the base system by default and only use the supplied dependency if the base system can't provide it or if there is a conflict of some sort. But I doubt it will do that, which means it is on the packagers to check the base system first before installing their own dependencies. Somehow I doubt they are going to do that, though.
g. RPM dependencies are calculated from files and SONAMEs, but can also be specified manually by the packager, including version inequalities of other packages.
Debian has this too, and I think it is actually a good deal more flexible than rpm, at least from what I remember from my brief stint with Red Hat back in the day. There's a reason Debian was able to have apt long before Red Hat/Fedora had yum.
https://www.debian.org/doc/man...
Well, then that's really a problem with the community not enforcing proper requirement standards that reflect reality on important packages.
This is the real problem. And I dare say it is 99% an Ubuntu problem because they really like to break everything with each subsequent release. Debian has been a rolling release distribution since forever and is renown for the incredible robustness with which packages can be shared between stable, testing, and even unstable, as well as the ease of transitioning from one to the other (ex: when testing becomes the new stable). And they have once or twice had to do some massive renaming of library dependencies, but managed without a hiccup, which is a testament to the quality of the deb system.
No, the problem is Ubuntu. Their versioning is a constant clusterfsck of broken, incompatible package naming. And they heavily abuse "virtual" packages for their own purposes which leads to the breakage in Samba like the GP described. It is horrible release management and is one of the many things wrong with Ubuntu. However, Ubuntu manages to stay more up-to-date, and has some pretty nifty userland tools, so I find myself using it much more than Debian. But I lament every time I have to upgrade, or if I want to move packages between versions.
Snap sounds like a system with some much-needed features, but what I would really like is for those features to be integrated into deb. Unfortunately, Ubuntu is following their usual pattern of aloofness. Both Debian and Ubuntu would benefit tremendously if they could work together to enhance deb. Transactional updates? Who doesn't want that? That is a great feature. But nope, that's not going to happen, apparently. We're going to end up with another Mir, or Upstart, or Compiz (shudder).
The details on this new packaging system are scarce--and I've checked--but it looks like a reimplementation of Docker,
I guess we'll find out more in time, because I too couldn't find any details on how this is implemented. If it does use containers (a la Docker), that would be really cool. As soon as Docker started getting more fleshed out, this was the first application I thought of that would be perfect for it.
An application being able to use alternative libraries is definitely a need on modern linux. I can't count the number of times that I needed to do massive upgrades of the system just to install a newer version of an app I was using. My only worry is that this will depend on the non-laziness of app developers to work well. Snap packages can use the underlying system, but only if app developers take the time to specify their dependencies, which is something they already don't want to do, apparently. So instead, they bundle their own libraries, even if they are already available on the system, and we get OSX bundles, which I'm not a big fan of. Ideally the snap system would default to using a system library if it meets a dependency and only a bundled library if that dependency is not met, but based on the scarce information available that doesn't seem to be the case.
It would also be nice if there was a quick way to determine library versions in all installed snaps, so that you can see which might be vulnerable to recent security errata, for example. Not sure if they have plans for tools like that, but it would sure be useful.