Each of the individual binaries cannot "be combined or interchanged with others like it to create different shapes or designs", which means it isn't "modular", but is "monolithic".
Yes...you...can! That is the whole f$@%@#$ing point of having multiple binaries! Where do people come up with this crap?
What you might ask instead is, why do no suitable replacements exist? Because nobody has written them....
Oh sure, I get that. You are absolutely correct. Proper monitoring requires making sure people can use the system for what it was intended for, not just publish artifical uptimes. The only point I was trying to make here is that systemd allows you to obtain status about running (or not) processes, memory/cpu usage, log events, dbus events, hardware events, forking, open ports, etc, that could be obtained before, but only in roundabout ways with specialized daemons. Systemd now provides a standardized and centralized infrastructure for doing all of that. It does not replace the need for monitoring tools, it just helps them do their job. And it makes containerization and automatic provisioning much easier.
True, systemd doesn't do monitoring per se, but it provides the infrastructure to do monitoring easily. Both Ganglia and Nagios rely on either a daemon installed that can collect data and report it, or on polling ports and such. Neither is really integrated into the system the way systemd is. I'm sure both projects will benefit greatly by their ability to now use systemd features for much of their work.
Well, it does kind of both in that you can join the public NTP pool, or maintain a private NTP server for your network with ntpd. Bottom line though is it's way overkill for what most people need. Your run of the mill server/desktop just needs a simple NTP client, which systemd-timesyncd is.
News to me. Ubuntu Gnome is working just fine without systemd on my desktop right now. They do plan on switching to systemd in the next release, but that is a separate issue.
If you don't have a setup system that establishs monitoring automatically and without manual intervention on all new systems
You do understand why systemd was created, right? To do exactly that! You may be proud of your collection of hacked together bash scripts, or maybe you use a third-party tool to do it, I don't know, but some of us think this capability should be a part of the OS itself. And now it is, thanks to systemd.
It's not just about auto-restart after crash. When the system knows something about its state, it can manage that state. So you can have a rule set that defines what to do when a particular service crashes. Or you can automatically start and stop services in response to system load. Tools like Puppet and Chef will have an actual infrastructure to use instead of needing to resort to a million polling hacks to do their job. There are a ton of reasons why it may be advantageous for the system to know something about its state (hey, I managed to do that without saying "cloud").
Even things as far removed as NTP functionality are now rolling into systemd (did you know systemd is trying to replace ntpd?).
You do realize that most distributions do not enable ntpd by default, right? And that the primary use of ntpd is for running an NTP server not time synchronization to an NTP server, right? Most distributions simply run ntpdate in a startup script to do a quick sync of the time/date during boot. So all systemd is doing is daemonizing the same functionality.
Reinventing APIs radically - The big case here is the basic OS interfaces for networked daemons.
It really isn't. It is providing additional functionality that applications can choose to use, or not (hence why some applications have dependencies on systemd). Nothing about POSIX has been deprecated with systemd. It just happens that the methods systemd provides are often more efficient or have other advantages (ex: monitoring), that you can't get with a bunch of random init scripts. So people want to use those features (surprise!).
For example, a traditional *nix daemon might be capable of managing its daemonization in an advanced way with the flexibility of the POSIX APIs (e.g. allowing a controlled 'restart' behavior for reducing downtime that starts a new daemon overlapped with the old one and uses some IPC to coordinate the handoff of live sockets, etc).
What you're basically saying here is that you can hack the POSIX socket implementation, but with systemd you have to do it differently. That is not really an argument about anything. If what you meant to say is that with systemd there is no way to manage service restarts with minimal downtime, that is completely false. The fact that you have to learn how to use systemd does not obviate its usefulness.
Also, a full conversion of a system to systemd doesn't work well with just leaving some daemons as traditional sysv-init style
Define "doesn't work well." Every distribution that implements systemd already does this, and probably will for the indefinite future because there is a lot of software out there that doesn't (and may never will) use systemd services.
It introduces a new latency in exposing new APIs.
The different ways that you keep using the term API makes me think you don't know what an API actually is. The ways in which APIs will be available to applications will not change with systemd. If systemd provides an API that an application wants to use, then it will of course depend on systemd, but that is really it. What you might be referring to is that systemd provides a bunch of new APIs that parallel kernel and glibc APIs, but doesn't really change the way APIs are developed or exposed to applications.
In general, while they minimally accommodate server-side daemon software, most of the development focus of systemd is for the desktop user's use-case.
This just keeps getting repeated. It's like a self-referencing Wikipedia article. Just because somebody said it doesn't mean it's true. Can you point to a whitepaper or design document somewhere that says "systemd is primarily developed to support desktops"? It's complete BS. Look, just take a minute to determine what Red Hat's primary market is. Hint: it is not the desktop. If it isn't obvious to you why systemd is great for servers, and in particular large systems of servers that regularly communicate with each other, need to be monitored remotely, and need to be completely auditable, then you have never really worked seriously with servers. You may be the kind of guy that likes to script your own toolkit to provide the functionality that sysV lacks. That's fine, but don't pretend systemd doesn't solve problems for servers. It does, a lot of them.
systemd, in spite of seeming to want to completely encapsulate or replace large swaths of well-regulated APIs from POSIX, doesn'
FYI, the scientists who did the work did not report it as "communication." As usual, the popular science writers were a bit over zealous in their choice of words.
My guess though is that you "hate vi" because it's strange and foreign to you and if you humbled yourself, took the time to learn some simple, easily memorizable things you'd probably change your tune.
No, it's really that I already have to know and be familiar with a number of things. I've used vi, very frustratingly, maybe three times. I don't care to spend more time learning it because i see it's complexity as just completely unnecessary. When I already have to know how to configure a dozen different services off the top of my head, manage cross-distribution complexities, script in half a dozen different languages, and keep up with new stuff coming out every month, the last thing I need is to keep a bunch of completely non-intuitive random letters and symbols in my head to do very basic every day things. I'll stick with nano, thanks.
Simple 3x5 card with the commands on it is all you need to be proficient enough to get most things done. Hell, a Post-It note would do.
That's just the point. I shouldn't need to refer to a reference sheet, notecard or otherwise, to edit a bloody text file!. I shouldn't need to spend two hours learning the difference between !#*$ and ?!$& just to go between a bunch of nonsensical modes (view, edit with insert, edit with overwrite, edit the end of a line, edit the middle of line, blah blah blah) in vi just to edit a text file. It is retarded.
With nano, you have a basic intuitive text editor. Navigate with the cursor keys (amazing, imagine that!), edit with backspace, delete, and just type letters to insert them ( more shocking things). When you need to save and quit, there is a help text at the bottom of the screen, Ctrl-x. That's it and that's why I like nano and hate vi. On top of that, nano is small and efficient and easily fits in a minimal environment. There is really no reason to not have it as a default text editor in any distribution.
However, as an admin, I have long ago standardized on VI for the simple reason that it's included by default on every single *nix variant out there. (At least, in my experience.)
While true, in my experience there is no reason why nano could not be included (and should be).
(though Linux does have non-stock application deployment packages available, like Puppet, that partially fill that last point).
You're kidding right? In addition to Puppet, which is a relative newcomer, there has been Satellite (http://www.redhat.com/products/enterprise-linux/satellite/) and Landscape (http://www.ubuntu.com/management/landscape-features) among others (Suse has one too). Where do you think the distros make their money? Now you may have meant there is no free application deployment and management software, but last time I checked Windows Server was definitely not free. If you need free, though, you can roll some scripts fairly easily, wrapping things like Kickstart with custom repositories (yum or apt) and services like Cobbler or Spacewalk (which Satellite is based off of), rsync, cron jobs, and ssh (for remote execution).
Linux AD-via-Samba quite simply doesn't even come close for the convenience of centralized GP maintenance,
I don't know what you are trying to say here. Why would you manage linux machines with a Samba domain? If you want the same functionality as AD on linux, FreeIPA is the most mature project, and it can integrate with AD via cross-realm trusts in the latest version. So you can manage a mixed Windows/Linux environment with the same core infrastructure. If instead you meant Samba as an AD domain controller for Windows, Samba4 is (mostly, 95%) a drop-in replacement for Windows Server. There are a few features missing, but you can provision and manage an AD domain via Samba with ease.
Well, if it's linux, FreeIPA is better because then you can take advantage of group policies that are designed to work with linux. If you use AD, you will get authentication and that's about it. Now if you have windows+linux it's a bigger problem. In our lab we went with AD forsaking the advantages of FreeIPA for our linux users, but you could also set up both servers with a shared trust. It's a bit more complicated, but this is something RedHat are trying to develop into a turnkey solution.
I agree it is difficult and challenging. It is not happening to me, but it recently happened to some friends of mine. What did they do? They tightened the belt, looked for temporary opportunities where they could, went back to school, and it is starting to turn around. I think they will be fine. They won't live a lucrative suburban life, but they didn't really want that anyway. They will survive at above the median wage, living in a modest apartment, driving old cars, and raising two children.
It would be ideal if it didn't happen at all, but really ask yourself, what's the alternative? Change, chance, and shifting jobs is a reality of life. We can't stop it. We can blame companies, but unless we are prepared to stop economic growth and development, we are fooling ourselves. Protectionism will not make the reality any easier to bear. They could have had government put a stop to the development of computers and robots that were taking jobs away from Americans in the 1970s. And then where would we be now? Still working shitty factory jobs for some other first world country that moved ahead and developed their technological sector.
I would argue that if the government is to do anything, it is to establish a solid safety net that will catch people as they fall and help them get back on their feet. Such a safety net used to exist, but it has been become far less effective than it used to be. Part of this is due to changing times, and part due to underfunding. So let's get it working again. The second, I would say, is helping to ensure that employees benefit from the growth of the companies they work for. I don't know exactly how to do this. It is not as simple as "wealth redistribution," but I think it needs to happen so that workers do not feel increasingly disconnected from their employers. Cultivate better relationships, and better ideas and a more productive work force will emerge.
Uh, this is not just scientific curiosity. There are some deep practical applications to such technology. Newsflash, malaria is still a big problem in the world and many other efforts to combat it are failing. If we can target the mosquito population I. Ways that don't involve copious amounts of DDT, or inhibit the ability of Mosquitos to act as a vector for the disease, we may make some significant inroads finally.
While the 12 Monkeys doomsday scenario is popular amongst techies, I don't think we should discount a useful tool just because of a possibility for misuse. The authors themselves recognize the need to use it responsibly and develop an appropriate regulatory framework. From the article,
Ecological changes caused by gene drives will be overwhelmingly due to the particular alteration and species, not by the CRISPR drive components. That means it doesn’t really make sense to ask whether we should use gene drives. Rather, we’ll need to ask whether it’s a good idea to consider driving this particular change through this particular population. While gene drives could tremendously benefit humans and the environment if used responsibly, the potentially accessible nature of the technology raises concerns about the risks of accidental effects or even intentional mismanagement. In a new paper published in Science, we specifically address the regulation and risk governance of gene drive applications to promote responsible use.
Even in universities, where wages compared to the private sector are usually lower, IT workers get paid more than double other typical staff. Wage depression is not a big problem right now as far as I can tell. IT workers may not make as much as they think they should make, but that is a different issue. When average IT income starts to approach median household income (instead of being in the top quintile), then we might have something to talk about.
Few industries don't require you to establish yourself and work your way up fresh out of college. Even medical students have to go through residency hell before they can get their first permanent position somewhere. In some places moving up is quick, but starting at a low wage fresh out of college is more normal than abnormal. IT has not had this, for the most part, until recently, so count yourselves lucky, but it can't last forever.
When computing and automation started playing a significant role in the workforce, this exact same conversation happened with respect to the then factory workers and office workers. Did all office or factory work disappear forcing everybody to work slave wages? No, the job landscape changed requiring fewer, but more highly skilled people. Some people will be out of a job. They will have to retrain or change fields. This is what happens. It may take some time, but ultimately those workers end up employed in new areas and growth in other industries occurs as a result.
Yes, but the CRISPR system can be designed to work precisely with a single species, because the targeting sequence can use non-homologous regions of genes that are similar between species. So in your horizontal gene transfer case it would die out after the transfer event into a new species. Another potential safeguard is to put the CRISPR system in a different locus from the mutation, so that horizontal gene transfer events would be very unlikely to transfer both functions into another species.
the mechanisms used to disseminate the genes to the target organisms are going to have to look rather virus like as it's unlikely you're going to try to catch every Cane Toad in the swamp to give them a shot.
The entire point behind the method is to not have to do this. You make one genetically engineered organism that then breeds passing on the desired trait, only in such a way that inheritance is biased toward the desired trait so that it isn't lost by "dilution" into the gene pool.
Yes, but the elegance (and limitation) of this system is that it requires sexual reproduction to work. So if the two organisms don't inter-breed, the traits cannot be passed.
Except they didn't say "entire ecosystem". They said "throughout the ecosystem," meaning engineered organism deliberately and purposefully breed with non-modified organisms thus creating a large-scale change in the ecosystem.
This is a it more elegant and controlled, in that it basically just suppresses reversion back to wild type after a mutation has occurred. Nothing else, no need to crest a bazillion untargeted copies all over the place. The process of gene editing (not new) becomes cleaner, which is something greatly needed.
Summary is an excerpt of an article highlighting some potential use of technology developed by George Church's lab at Harvard (and others). It is actually some pretty incredible stuff. Church's first published the adaption of the CRISPR system to gene editing in eukaryotes a few years ago. Basically, it works like this. CRISPR is a bacterial defense system where an enzyme (endonuclease) is directed to cut a specific DNA sequence by it's directly adjacent targeting sequence. Bacteria use this to protect themselves from viruses. When a virus tries to insert itself into the genome of a bacterium, CRISPR will cleave that sequence (if the bacterium has the appropriate targeting system) and subsequent DNA repair processes will occur that will excise the viral sequence. You can think of it as a pseudo-immunity system for bacteria against viruses. Like other DNA sequences, CRISPR sequences can be transferred between bacteria in a population allowing for broad-ranging resistance to viral infection to occur within a bacterial community.
The innovation by Church's group is to put the CRISPR system in eukaryotes. Introducing modified genes by homologous recombination has been around for a long time, but the problem with most eukaryotes is they have multiple copies of each chromosome. So a modification in one copy will get diluted out over several rounds of replication. By including the CRISPR system in the mutation that targets the original gene, a mechanism is supplied to allow a modified gene to quickly spread throughout the population. This makes genetic modification of eukaryotes much more efficient and easier to control.
Now, while safely applies in a laboratory system, the ecological consequences of using such a system in a natural setting are unclear. This is the purpose of the article: to raise some of the issues and possibilities to begin a discussion about how such a system might be used safely and what sort of regulations may need to be put into place. The article does quite a good job of illustrating some scenarios. Here is what I consider the meat of it, but of course other scenarios exist as well.
Why and how might we use gene drives to intervene in a particular ecosystem? Our earlier example is perhaps the most compelling: we might use gene drives to control malaria by altering Anopheles mosquitoes that transmit the disease. Anti-malarial medicines and insecticides are losing effectiveness due to evolving resistance, while a vaccine remains out of reach despite intense research and investment. Gene drives, in contrast, might spread genes conferring malaria resistance through the mosquito populations with few if any effects on other species. Alternatively, they might be able to reduce or even eliminate the mosquitoes for long enough to permanently eradicate the malaria parasite. Similar strategies could work for other organisms that spread disease.
Just want to put that out there so that a somewhat productive conversation can hopefully happen here.
It's really amazing how much revisionist rubbish gets spouted on Slashdot and treated as gospel. Companies have always since forever viewed their employees from the perspective of a cost-benefit analysis. That is no different now than it was in the 50s or earlier. Why do you think we have things like unions, labor laws, OSHA regulations, minimum wage, etc? When a company seeks to cut costs they will, plain and simple.
The reason companies were willing to train workers in the past was because they had to, not because they were somehow more benevolent toward their employees. Factory and office jobs were on the upswing. People coming out of school, not necessarily high school, didn't have the skills they needed, so they trained them. This, by the way, was a minimum wage job, and factories were installed in small rural towns for a reason.
Now it is different. We are no longer talking about minimum wage factory jobs. We are talking about highly skilled $100k+/yr + benefits tech jobs. It really shouldn't be surprising to anyone why a company wouldn't want to invest in a year of downtime in training, especially when people hop jobs in 2-3 yrs. Yes, a PHP developer can probably become a Perl developer rather quickly, but a DBA cannot become a Perl developer as easily. And why should a company be forced to pay for that anyway? If they can't hire who they need locally, they should be able to look elsewhere. When a company wants to hire fresh grads, how many of those are Americans? Some, but not many.
Tech is experiencing right now what every other field has experienced in the past. They have been shielded from it until fairly recently, but it can't be avoided anymore. The tech workers that can adapt, of their own volition, will probably not have trouble finding decent jobs. The ones that whine and complain because great high paying jobs aren't just handed to them fresh out of college will struggle a bit. Welcome to the rest of the world gentleman. It is not going to go away.
No, Red Hat 6 series used kernel 2.2 and libc6, and Corel definitely ran on it, I remember doing it. Don't know what the problem with Debian was, but it may have been a Wine issue.
Slashdot Mirror
Each of the individual binaries cannot "be combined or interchanged with others like it to create different shapes or designs", which means it isn't "modular", but is "monolithic".
Yes...you...can! That is the whole f$@%@#$ing point of having multiple binaries! Where do people come up with this crap?
What you might ask instead is, why do no suitable replacements exist? Because nobody has written them....
Oh sure, I get that. You are absolutely correct. Proper monitoring requires making sure people can use the system for what it was intended for, not just publish artifical uptimes. The only point I was trying to make here is that systemd allows you to obtain status about running (or not) processes, memory/cpu usage, log events, dbus events, hardware events, forking, open ports, etc, that could be obtained before, but only in roundabout ways with specialized daemons. Systemd now provides a standardized and centralized infrastructure for doing all of that. It does not replace the need for monitoring tools, it just helps them do their job. And it makes containerization and automatic provisioning much easier.
True, systemd doesn't do monitoring per se, but it provides the infrastructure to do monitoring easily. Both Ganglia and Nagios rely on either a daemon installed that can collect data and report it, or on polling ports and such. Neither is really integrated into the system the way systemd is. I'm sure both projects will benefit greatly by their ability to now use systemd features for much of their work.
Well, it does kind of both in that you can join the public NTP pool, or maintain a private NTP server for your network with ntpd. Bottom line though is it's way overkill for what most people need. Your run of the mill server/desktop just needs a simple NTP client, which systemd-timesyncd is.
News to me. Ubuntu Gnome is working just fine without systemd on my desktop right now. They do plan on switching to systemd in the next release, but that is a separate issue.
If you don't have a setup system that establishs monitoring automatically and without manual intervention on all new systems
You do understand why systemd was created, right? To do exactly that! You may be proud of your collection of hacked together bash scripts, or maybe you use a third-party tool to do it, I don't know, but some of us think this capability should be a part of the OS itself. And now it is, thanks to systemd.
It's not just about auto-restart after crash. When the system knows something about its state, it can manage that state. So you can have a rule set that defines what to do when a particular service crashes. Or you can automatically start and stop services in response to system load. Tools like Puppet and Chef will have an actual infrastructure to use instead of needing to resort to a million polling hacks to do their job. There are a ton of reasons why it may be advantageous for the system to know something about its state (hey, I managed to do that without saying "cloud").
Even things as far removed as NTP functionality are now rolling into systemd (did you know systemd is trying to replace ntpd?).
You do realize that most distributions do not enable ntpd by default, right? And that the primary use of ntpd is for running an NTP server not time synchronization to an NTP server, right? Most distributions simply run ntpdate in a startup script to do a quick sync of the time/date during boot. So all systemd is doing is daemonizing the same functionality.
Reinventing APIs radically - The big case here is the basic OS interfaces for networked daemons.
It really isn't. It is providing additional functionality that applications can choose to use, or not (hence why some applications have dependencies on systemd). Nothing about POSIX has been deprecated with systemd. It just happens that the methods systemd provides are often more efficient or have other advantages (ex: monitoring), that you can't get with a bunch of random init scripts. So people want to use those features (surprise!).
For example, a traditional *nix daemon might be capable of managing its daemonization in an advanced way with the flexibility of the POSIX APIs (e.g. allowing a controlled 'restart' behavior for reducing downtime that starts a new daemon overlapped with the old one and uses some IPC to coordinate the handoff of live sockets, etc).
What you're basically saying here is that you can hack the POSIX socket implementation, but with systemd you have to do it differently. That is not really an argument about anything. If what you meant to say is that with systemd there is no way to manage service restarts with minimal downtime, that is completely false. The fact that you have to learn how to use systemd does not obviate its usefulness.
Also, a full conversion of a system to systemd doesn't work well with just leaving some daemons as traditional sysv-init style
Define "doesn't work well." Every distribution that implements systemd already does this, and probably will for the indefinite future because there is a lot of software out there that doesn't (and may never will) use systemd services.
It introduces a new latency in exposing new APIs.
The different ways that you keep using the term API makes me think you don't know what an API actually is. The ways in which APIs will be available to applications will not change with systemd. If systemd provides an API that an application wants to use, then it will of course depend on systemd, but that is really it. What you might be referring to is that systemd provides a bunch of new APIs that parallel kernel and glibc APIs, but doesn't really change the way APIs are developed or exposed to applications.
In general, while they minimally accommodate server-side daemon software, most of the development focus of systemd is for the desktop user's use-case.
This just keeps getting repeated. It's like a self-referencing Wikipedia article. Just because somebody said it doesn't mean it's true. Can you point to a whitepaper or design document somewhere that says "systemd is primarily developed to support desktops"? It's complete BS. Look, just take a minute to determine what Red Hat's primary market is. Hint: it is not the desktop. If it isn't obvious to you why systemd is great for servers, and in particular large systems of servers that regularly communicate with each other, need to be monitored remotely, and need to be completely auditable, then you have never really worked seriously with servers. You may be the kind of guy that likes to script your own toolkit to provide the functionality that sysV lacks. That's fine, but don't pretend systemd doesn't solve problems for servers. It does, a lot of them.
systemd, in spite of seeming to want to completely encapsulate or replace large swaths of well-regulated APIs from POSIX, doesn'
FYI, the scientists who did the work did not report it as "communication." As usual, the popular science writers were a bit over zealous in their choice of words.
http://www.phdcomics.com/comic...
My guess though is that you "hate vi" because it's strange and foreign to you and if you humbled yourself, took the time to learn some simple, easily memorizable things you'd probably change your tune.
No, it's really that I already have to know and be familiar with a number of things. I've used vi, very frustratingly, maybe three times. I don't care to spend more time learning it because i see it's complexity as just completely unnecessary. When I already have to know how to configure a dozen different services off the top of my head, manage cross-distribution complexities, script in half a dozen different languages, and keep up with new stuff coming out every month, the last thing I need is to keep a bunch of completely non-intuitive random letters and symbols in my head to do very basic every day things. I'll stick with nano, thanks.
Simple 3x5 card with the commands on it is all you need to be proficient enough to get most things done. Hell, a Post-It note would do.
That's just the point. I shouldn't need to refer to a reference sheet, notecard or otherwise, to edit a bloody text file!. I shouldn't need to spend two hours learning the difference between !#*$ and ?!$& just to go between a bunch of nonsensical modes (view, edit with insert, edit with overwrite, edit the end of a line, edit the middle of line, blah blah blah) in vi just to edit a text file. It is retarded.
With nano, you have a basic intuitive text editor. Navigate with the cursor keys (amazing, imagine that!), edit with backspace, delete, and just type letters to insert them ( more shocking things). When you need to save and quit, there is a help text at the bottom of the screen, Ctrl-x. That's it and that's why I like nano and hate vi. On top of that, nano is small and efficient and easily fits in a minimal environment. There is really no reason to not have it as a default text editor in any distribution.
However, as an admin, I have long ago standardized on VI for the simple reason that it's included by default on every single *nix variant out there. (At least, in my experience.)
While true, in my experience there is no reason why nano could not be included (and should be).
(though Linux does have non-stock application deployment packages available, like Puppet, that partially fill that last point).
You're kidding right? In addition to Puppet, which is a relative newcomer, there has been Satellite (http://www.redhat.com/products/enterprise-linux/satellite/) and Landscape (http://www.ubuntu.com/management/landscape-features) among others (Suse has one too). Where do you think the distros make their money? Now you may have meant there is no free application deployment and management software, but last time I checked Windows Server was definitely not free. If you need free, though, you can roll some scripts fairly easily, wrapping things like Kickstart with custom repositories (yum or apt) and services like Cobbler or Spacewalk (which Satellite is based off of), rsync, cron jobs, and ssh (for remote execution).
Linux AD-via-Samba quite simply doesn't even come close for the convenience of centralized GP maintenance,
I don't know what you are trying to say here. Why would you manage linux machines with a Samba domain? If you want the same functionality as AD on linux, FreeIPA is the most mature project, and it can integrate with AD via cross-realm trusts in the latest version. So you can manage a mixed Windows/Linux environment with the same core infrastructure. If instead you meant Samba as an AD domain controller for Windows, Samba4 is (mostly, 95%) a drop-in replacement for Windows Server. There are a few features missing, but you can provision and manage an AD domain via Samba with ease.
Well, if it's linux, FreeIPA is better because then you can take advantage of group policies that are designed to work with linux. If you use AD, you will get authentication and that's about it. Now if you have windows+linux it's a bigger problem. In our lab we went with AD forsaking the advantages of FreeIPA for our linux users, but you could also set up both servers with a shared trust. It's a bit more complicated, but this is something RedHat are trying to develop into a turnkey solution.
I agree it is difficult and challenging. It is not happening to me, but it recently happened to some friends of mine. What did they do? They tightened the belt, looked for temporary opportunities where they could, went back to school, and it is starting to turn around. I think they will be fine. They won't live a lucrative suburban life, but they didn't really want that anyway. They will survive at above the median wage, living in a modest apartment, driving old cars, and raising two children.
It would be ideal if it didn't happen at all, but really ask yourself, what's the alternative? Change, chance, and shifting jobs is a reality of life. We can't stop it. We can blame companies, but unless we are prepared to stop economic growth and development, we are fooling ourselves. Protectionism will not make the reality any easier to bear. They could have had government put a stop to the development of computers and robots that were taking jobs away from Americans in the 1970s. And then where would we be now? Still working shitty factory jobs for some other first world country that moved ahead and developed their technological sector.
I would argue that if the government is to do anything, it is to establish a solid safety net that will catch people as they fall and help them get back on their feet. Such a safety net used to exist, but it has been become far less effective than it used to be. Part of this is due to changing times, and part due to underfunding. So let's get it working again. The second, I would say, is helping to ensure that employees benefit from the growth of the companies they work for. I don't know exactly how to do this. It is not as simple as "wealth redistribution," but I think it needs to happen so that workers do not feel increasingly disconnected from their employers. Cultivate better relationships, and better ideas and a more productive work force will emerge.
Uh, this is not just scientific curiosity. There are some deep practical applications to such technology. Newsflash, malaria is still a big problem in the world and many other efforts to combat it are failing. If we can target the mosquito population I. Ways that don't involve copious amounts of DDT, or inhibit the ability of Mosquitos to act as a vector for the disease, we may make some significant inroads finally.
While the 12 Monkeys doomsday scenario is popular amongst techies, I don't think we should discount a useful tool just because of a possibility for misuse. The authors themselves recognize the need to use it responsibly and develop an appropriate regulatory framework. From the article,
Ecological changes caused by gene drives will be overwhelmingly due to the particular alteration and species, not by the CRISPR drive components. That means it doesn’t really make sense to ask whether we should use gene drives. Rather, we’ll need to ask whether it’s a good idea to consider driving this particular change through this particular population. While gene drives could tremendously benefit humans and the environment if used responsibly, the potentially accessible nature of the technology raises concerns about the risks of accidental effects or even intentional mismanagement. In a new paper published in Science, we specifically address the regulation and risk governance of gene drive applications to promote responsible use.
Three things:
Even in universities, where wages compared to the private sector are usually lower, IT workers get paid more than double other typical staff. Wage depression is not a big problem right now as far as I can tell. IT workers may not make as much as they think they should make, but that is a different issue. When average IT income starts to approach median household income (instead of being in the top quintile), then we might have something to talk about.
Few industries don't require you to establish yourself and work your way up fresh out of college. Even medical students have to go through residency hell before they can get their first permanent position somewhere. In some places moving up is quick, but starting at a low wage fresh out of college is more normal than abnormal. IT has not had this, for the most part, until recently, so count yourselves lucky, but it can't last forever.
When computing and automation started playing a significant role in the workforce, this exact same conversation happened with respect to the then factory workers and office workers. Did all office or factory work disappear forcing everybody to work slave wages? No, the job landscape changed requiring fewer, but more highly skilled people. Some people will be out of a job. They will have to retrain or change fields. This is what happens. It may take some time, but ultimately those workers end up employed in new areas and growth in other industries occurs as a result.
Yes, but the CRISPR system can be designed to work precisely with a single species, because the targeting sequence can use non-homologous regions of genes that are similar between species. So in your horizontal gene transfer case it would die out after the transfer event into a new species. Another potential safeguard is to put the CRISPR system in a different locus from the mutation, so that horizontal gene transfer events would be very unlikely to transfer both functions into another species.
the mechanisms used to disseminate the genes to the target organisms are going to have to look rather virus like as it's unlikely you're going to try to catch every Cane Toad in the swamp to give them a shot.
The entire point behind the method is to not have to do this. You make one genetically engineered organism that then breeds passing on the desired trait, only in such a way that inheritance is biased toward the desired trait so that it isn't lost by "dilution" into the gene pool.
Yes, but the elegance (and limitation) of this system is that it requires sexual reproduction to work. So if the two organisms don't inter-breed, the traits cannot be passed.
Except they didn't say "entire ecosystem". They said "throughout the ecosystem," meaning engineered organism deliberately and purposefully breed with non-modified organisms thus creating a large-scale change in the ecosystem.
This is a it more elegant and controlled, in that it basically just suppresses reversion back to wild type after a mutation has occurred. Nothing else, no need to crest a bazillion untargeted copies all over the place. The process of gene editing (not new) becomes cleaner, which is something greatly needed.
Summary is an excerpt of an article highlighting some potential use of technology developed by George Church's lab at Harvard (and others). It is actually some pretty incredible stuff. Church's first published the adaption of the CRISPR system to gene editing in eukaryotes a few years ago. Basically, it works like this. CRISPR is a bacterial defense system where an enzyme (endonuclease) is directed to cut a specific DNA sequence by it's directly adjacent targeting sequence. Bacteria use this to protect themselves from viruses. When a virus tries to insert itself into the genome of a bacterium, CRISPR will cleave that sequence (if the bacterium has the appropriate targeting system) and subsequent DNA repair processes will occur that will excise the viral sequence. You can think of it as a pseudo-immunity system for bacteria against viruses. Like other DNA sequences, CRISPR sequences can be transferred between bacteria in a population allowing for broad-ranging resistance to viral infection to occur within a bacterial community.
The innovation by Church's group is to put the CRISPR system in eukaryotes. Introducing modified genes by homologous recombination has been around for a long time, but the problem with most eukaryotes is they have multiple copies of each chromosome. So a modification in one copy will get diluted out over several rounds of replication. By including the CRISPR system in the mutation that targets the original gene, a mechanism is supplied to allow a modified gene to quickly spread throughout the population. This makes genetic modification of eukaryotes much more efficient and easier to control.
Now, while safely applies in a laboratory system, the ecological consequences of using such a system in a natural setting are unclear. This is the purpose of the article: to raise some of the issues and possibilities to begin a discussion about how such a system might be used safely and what sort of regulations may need to be put into place. The article does quite a good job of illustrating some scenarios. Here is what I consider the meat of it, but of course other scenarios exist as well.
Why and how might we use gene drives to intervene in a particular ecosystem? Our earlier example is perhaps the most compelling: we might use gene drives to control malaria by altering Anopheles mosquitoes that transmit the disease. Anti-malarial medicines and insecticides are losing effectiveness due to evolving resistance, while a vaccine remains out of reach despite intense research and investment. Gene drives, in contrast, might spread genes conferring malaria resistance through the mosquito populations with few if any effects on other species. Alternatively, they might be able to reduce or even eliminate the mosquitoes for long enough to permanently eradicate the malaria parasite. Similar strategies could work for other organisms that spread disease.
Just want to put that out there so that a somewhat productive conversation can hopefully happen here.
It's really amazing how much revisionist rubbish gets spouted on Slashdot and treated as gospel. Companies have always since forever viewed their employees from the perspective of a cost-benefit analysis. That is no different now than it was in the 50s or earlier. Why do you think we have things like unions, labor laws, OSHA regulations, minimum wage, etc? When a company seeks to cut costs they will, plain and simple.
The reason companies were willing to train workers in the past was because they had to, not because they were somehow more benevolent toward their employees. Factory and office jobs were on the upswing. People coming out of school, not necessarily high school, didn't have the skills they needed, so they trained them. This, by the way, was a minimum wage job, and factories were installed in small rural towns for a reason.
Now it is different. We are no longer talking about minimum wage factory jobs. We are talking about highly skilled $100k+/yr + benefits tech jobs. It really shouldn't be surprising to anyone why a company wouldn't want to invest in a year of downtime in training, especially when people hop jobs in 2-3 yrs. Yes, a PHP developer can probably become a Perl developer rather quickly, but a DBA cannot become a Perl developer as easily. And why should a company be forced to pay for that anyway? If they can't hire who they need locally, they should be able to look elsewhere. When a company wants to hire fresh grads, how many of those are Americans? Some, but not many.
Tech is experiencing right now what every other field has experienced in the past. They have been shielded from it until fairly recently, but it can't be avoided anymore. The tech workers that can adapt, of their own volition, will probably not have trouble finding decent jobs. The ones that whine and complain because great high paying jobs aren't just handed to them fresh out of college will struggle a bit. Welcome to the rest of the world gentleman. It is not going to go away.
No, Red Hat 6 series used kernel 2.2 and libc6, and Corel definitely ran on it, I remember doing it. Don't know what the problem with Debian was, but it may have been a Wine issue.