How much of a salary premium is the question. Software developers at their current average pay, are comparable to other highly trained professionals (enginnering, lawyers, doctors, researchers, etc). How much more do you think they need to make? How much do you think is sustainable for a company to pay? Remember that you aren't talking about one or two individuals, but in some cases upwards of 2/3 of the entire workforce at a company.
If bumping salaries by 20-25% was all it took, they would probably do it. But for companies like Google, it is not a small subset of salaries, it is the majority of their workforce.
Companies don't deserve to exist, but if they don't exist there is nobody to employ you or make products for you to buy. Not every company is a Google-size monolith. There are quite a few that barely stay in the black each quarter. I'm not saying companies should be given a free reign to do whatever they want, just that discussions like this on \. are very one-sided. There are multiple viewpoints to consider and consequences to every course of action that must be weighed for pros and cons.
Right. The complaint by companies and hiring managers is that, even by paying 3x the average annual wage, they aren't able to find qualified people. So instead of A) trying to pay 5x the average annual wage which would not likely be sustainable for the company, or B) not hire anybody and not be able to grow the company or stay competitive in the market, they are opting for C) hiring H1-B workers (which the law requires to be paid at least the prevailing wage). It seems like a pretty clear situation to me. The job market for software developers is excellent, because IT demand is continuing to grow tremendously, and it isn't likely to change any time soon, but that doesn't mean there are infinite resources available to allocate to paying for IT salaries.
Uh, huh. Why yes, clearly instead of paying someone a paltry $100,000/yr they should raise the pay to $500,000/yr. I mean companies are rich, right? They can afford to pay their entire workforce salaries that fall in the top 1% income bracket nationally. For Google, this would only be about $26 billion dollars. No sweat.
The H1-B program is not for local worker shortages "No good candidates in Silicon Valley", it's for NATIONAL shortages as in "No qualified workers in the United States".
I love this completely one-sided viewpoint so prevalent on \. First of all, a shortage doesn't mean none, it means fewer than able to meet demand. Second,
Then by definition you were not paying competitive rates.
In May 2012, the median annual wage for all workers was $34,750, and the median salary for a software developer was $93,350 per year! That's from the Bureau of Labor Statistics. I know it's popular on \. to not care about the ability of a company to start, grow, or even sustain itself...but when you have to pay 3x the average salary for labor, and unemployment rates are less than the national average, and companies are faced with either hiring incompetent workers or increasing their offer to 4x or 5x the national average (still not guaranteeing that they will be able to hire someone qualified), there is a shortage, and that is what the H1-B program is intended to address.
Macrogen up in Korea has the highest certifications available - better than CLIA in terms of raw data quality - guaranteed to be as good as if Illumina did the sequencing for you itself. And they offer 30X whole genome for $1,000 (an extra $100 to extract the DNA from saliva). They also offer combined whole genome and 100X exome for $1,500.
Right, sure, go ahead and send your sequencing to Korea. What is the cost to have it done by MacrogenUSA, the subsidiary that can actually do FDA-approved work? $1000 doesn't even cover the cost of the materials, so who knows what they are pulling to advertise that.
But 23andMe was pure speech - there weren't offering anything physical - only information.
The issue is, what do people do with that information? If they run out and start seeking a bunch of new age remedies for perceived ailments because they don't understand enough about genetics to know what they are looking at, then it can be a real public health problem. Just look at vaccines. Jenny McCarthy wasn't even selling information, she was just giving it away for free, and it panicked enough people that they made some really dangerous decisions affecting their children and other people around them.
There is no tangible difference between "doing something physical" and "doing something on the internet." A genetic counselor doesn't do anything physical. They just talk to you. But they still have to be licensed to operate in their official capacity.
And getting back on topic, 23andMe was focused on just that problem: putting together a website that could help ordinary people understand their genomes. And the FDA shut them down
The FDA requires analytical verification ( does the test or service accurately and reproducibly provide the data that you are saying within acceptable margins of error? ) and clinical validation ( can the results of the test or service be reliably associated with specific health outcomes, after accounting for statistical significance and effect sizes? ) for medical devices and services sold in the USA. 23andMe has to go through this process as does every medical services company. This is not a conspiracy. The interpretation of medical data is not completely straightforward and requires a fair amount of expertise. Drug companies and device manufacturers like to whine about the FDA because they want the freedom to sell their snake oil to the public, but if you want medical decisions based on the careful consideration of the available science and not emotional manipulation, what the FDA does is essential.
The problem is that it takes quite a bit of expertise to use all of these tools. It's a lot like Linux in the early days before easy to install Linux "Distributions"
No, it is not like that at all. If it were a simple matter of an easy to execute set of programs, those tools would have been written a long time ago. There are, in fact, plenty of easy to use tools out there already. The challenging part is the nuance and interpretation of the data: understanding the error rates and data biases, knowing how to look for things like structural variation, understanding different types of mutation and how they may affect downstream processes, knowing how to verify your data and determine whether the result is trustworthy. With genetic data there is the additional aspect of inheritance. Probability is inherent to the interpretation of most of analyses; a straightforward yes or no is much less common. It takes many years of study and experience to get to this level. Some analyses are straightforward enough to be automated, but not all of them. Which is why we aren't going to get rid of doctors any time soon.
The 'raw' data they supply isn't really raw at all, but a processed list of several hundred thousand variant calls:
No, but it is cheap, which is not to be underestimated. If we want affordable healthcare, we have to care about cost and not just the new shiny. The other thing is, focusing on select variants allows them to do a targeted analysis. In a world plagued by systems biology, people like to think a "global picture" is always better, but having some idea what you are looking for before you start collecting data makes your statistical analysis, you know...meaningful.
At this point, SNP genotyping is pretty much obsolete for health-related uses because you can now get a full genome sequence for about $1,000 from just a few drop of saliva
No way. Two lanes of HiSeq (the most economical method) will net you about 10X coverage (assuming uniform coverage, which you won't get) for about $3000 at academic prices. For SNP calling, 20-30X is usually considered the minimum, with 50-60X being preferred. And then there is still the cost of DNA isolation, library prep, QC to factor in. The $1000 (human) genome is still quite a ways away.
SNP genotyping can still be useful for detecting losses or duplications of large parts of a chromosome ("structural" variations)
Maybe you are just being lazy with your terminology, but SNP genotyping, by definition, does not look for structural variations. SNP == single nucleotide polymorphism. There are separate arrays to look for these variations, but they are not SNP arrays. That said, while whole genome data might be better suited for this type of analysis, it is far from trivial. Usually targeted amplification of specific loci is used, not whole genome data. There is a tendency to believe that more data is always better, but genome data is not easy to understand. If you ever thought pharmaceutical research was sloppy due to poor statistical analyses and over interpretation of results, multiply this by 1000 for genome studies.
But the head of the FDA at the time was a medical doctor herself - so she was sympathetic to that view point even if it was not supported by the science.
I partially agree, but there is quite a bit of disagreement in the field about how significant these associations are and how meaningful they are with respect to medicine. It is easy to scare people and then use that to sell medications or treatments that may or may not work, so going through experts that have studied extensively and remain up-to-date in the field is good, in my opinion. Lots of people try to self-diagnose from websites already. I don't think that is leading to better healthcare outcomes. If you are worried about people who just want to make some quick cash, I would worry more about all of the companies selling tests and devices than I would about the doctors themselves.
Hanford was the site of the first nuclear reactor of its design, used to produce plutonium during WWII. The site was subsequently expanded to produce more plutonium, and some energy, through the Cold War. It is so messed up because of a lot of crap that went on during that time period: not knowing anything about industrial nuclear reactors, not having any kind of waste storage or processing plan, lots of scale-up, Cold War secrecy, etc. So, yeah, Hanford is a mess, but I think it is wrong to inhibit any kind of progress due to problems that were mostly documented more than 40 years ago. No waste was shipped to Hanford. The current DOE is very aware of the problems at Hanford and is actively trying to clean it up, but it takes a lot of time...and you need somewhere to store the waste. Without a waste storage facility, there is no way to clean up Hanford, and the barrels are going to keep leaking because most of them are more than 50 years old (never intended to be long-term waste storage).
It is not a Nature or Science paper because it is just a standard target enrichment library. They've been doing this for a long time to profile things like cancer markers, disease panels, etc. These guys just made a library to target viruses. That's all. It can do both RNA and DNA because they do a reverse transcriptase reaction first (required anyway to sequence RNA), and then pull down the resulting cDNA along with DNA and sequence it. Kind of cool, but not really groundbreaking.
Those desiring the change are the ones that need to explain why the change is needed/desirable in the first place.
They have, many times and in different places. If you didn't know that, maybe you should do some research.
I said that the arguments typically presented were weak and unreasonable.
So you do know that arguments and rationale have been made. Ok, how about a substantive counterargument then. Preferably one that actually addresses the arguments given and doesn't just dismiss them as "weak and unreasonable."
The ridiculously common command line that you wrote above fails on many/most distros that have chosen systemd as a default. These systems have no syslog at all.
Every distro that I know of (Red Hat, CentOS, Debian, Ubuntu, Arch) currently installs syslog alongside journald. If you don't have syslog installed, install it, and take it up with your distro for not including it. What your distro decides and decides not to bundle is not the fault of systemd.
Installing syslog on such a system doesn't log systems messages unless you reroute all of them away form systemd/journalctl.
Newsflash: you cannot have two logging daemons listening on the same socket and receiving the same system calls. If you want two logging daemons, one will need to forward that information to the other. JournalD does this, syslog does not, hence the current arrangement where journald forwards logging information to syslog.
But, do carry on insinuating that my log usage or viewing habits are inferior or inadequate because they use the preferred methods of the last 20+ years, rather than your preferred and totally new method. While we're at it, how about the fact that the log file itself is now formatted differently and is binary encoded rather than text. No, that doesn't break anything, 'except old people stuff'.
Wow, defensive much? Whether or not they are inferior or inadequate depends on what you are doing. They are for some people, and journalctl is the solution. If you don't want to use it, that's your choice. Do continue using your method of 20+ years, but you will be missing out on the advantages that journald provides.
As for dependencies, log dependencies are broken, despite your childish refrain of veiled insults. Startup scripts are broken. and the list of broken projects/packages/scripts goes on and on.
If there is a new init system, then old init scripts will be have to rewritten to use it. There is a compatibility method to ease the migration, but a migration will still be necessary eventually. I'm not sure why this is so shocking to you. Your argument basically boils down to "systemd is bad because it isn't sysvinit." If you don't see why that is a ridiculous argument, I don't know what else to say.
These facts aside, you're still arguing with insults.
I am not doing that at all. I am explaining to you how systemd works. You are the one taking it as an insult.
You're not presenting arguments that demonstrate any actual value of the new system/way.
Why do I need to present the arguments in favor of systemd, again, when they have already been made repeatedly elsewhere? At any rate, systemd advocacy is not the purpose of my reply. I am just explaining to you how it works and dispelling the myths that you are perpetuating.
All you've said, like I claimed in the GP, is that my 'unwillingness to accept the new way is because I'm inadequate in my use of Linux and that real users like yourself need all this old shit gone because it's old'.
Nowhere did I say anything like that.
I still say that this is not a valid or logical reason.
It's a good thing that is not one of the reasons then. There is a pretty good summary here (since you insist), https://wiki.debian.org/Debate...
You are all completely fucked, and clearly show your lack of maturity and competence.
What an odd statement.
Look AC, learn something about the way the linux kernel works, and then maybe you will be able to understand the problem. There can only be one logging daemon attached to/dev/log. If it is journald it is journald, if it is syslog it is syslog. If you want both, one has to forward information to the other, and the amount and speed by which that forwarding can take place (via sockets) is limited by the kernel. So syslog missing messages that journald forwards, is an inherent limitation of the system and not the (direct) fault of journald. Since all of the logging information (more than syslog collects on its own) is there in the journal, and you just have to learn one command to get at it (journalctl), it is not seen as the travesty it is made out to be by the anti-systemd crowd.
Well, if you understood anything about the project, you would know that rebuilding the init system and rebuilding the log system are two separate projects. There are independent rationales for each of them. You are free to disagree, of course, but they exist. And a counterargument of "it works for me" is less than useless in a discussion about whether the change is necessary. Given that there are a lot of people who do think a change is necessary, you should make a better attempt to understand why and make a more substantive counterargument. Saying "Red Hat is an abomination" is not an argument.
Nor does it mean that the commands for accessing and controlling the system log needs to be abruptly deprecated
cat/var/log/syslog | grep
has not been deprecated. If that is the extent of your log analysis, it still works just fine. Just know that, in that case, you are getting the log information from syslog, not from journald, and there are inherent limitations to the forwarding mechanism that journald uses to share logging information with syslog. If you want to have complete access to all of the logging that journald does, you need to use its own interface, journalctl. It is really that simple and does not require a tremendous effort.
Nor does it mean that breaking many dependencies is acceptable.
No dependencies have been broken. If your log analysis tools require grep scraping a text log, they need to be rewritten to take full advantage of the data that journald provides. That is not a broken dependency. That is the normal course of software development that occurs when underlying system components are changed.
That's not to say the OS can't change, but the new pieces must be backwards compatible
Sure. But the limitation here is not with systemd, but the fact that systemd has to communicate with syslog through a socket, and the socket has a limited buffer for storing queued messages. So if you need critical, timing-dependent log messages, you really need to use journalctl. If you refuse to use journalctl then you are shooting yourself in the foot and complaining that it hurts.
No, but it is in the areas that matter to most people. The thing is, people (at least the people I know) don't spend a lot of time working on older documents. They are working on new documents. And when they upgrade their Office version, usually everybody is upgrading their Office version, so Office 2003 vs. Office 2013 incompatibilities don't matter to very many people. But there is no LibreOffice version that will import a complex Word document of any version without some major flaws (minor flaws are usually ok). Floating figures that move around or disappear, captions that disappear, tables that get mangled, line art that doesn't render or renders incorrectly.... If you are writing a simple office memo, LibreOffice works perfectly fine, but many people use it to do complex formatting, and for those people the incompatibilities are a big problem.
There is perfect and then there is perfect. It is true, Microsoft Office compatibility is the last major remaining issue that most of the people I talk to care about. They will even use LibreOffice on Windows, they love the idea of LibreOffice, but Microsoft Office file formats are the currency of document exchange among many academics. It is usually not things like font substitution that matter to them, though. It is tables, charts, floating figures, line art, 3D arrows, OLE objects, etc. If the margins are bit off when you send a document to somebody, no big deal, but if the table with the latest data in a progress report to the NIH doesn't show up or gets mangled, that screws the pooch. LibreOffice is really close, but it is that last 1-2% that is really critical for many people to switch. OOXML has made this process a lot easier, but it is still a beast of a file format.
Um, sure ok, if you want to think about it that way. I see what you are saying, but the question relevant to the discussion is "How do you share a passphrase when its only representation on the system is as a hashed key?" That is the question that started off the whole discussion. For example, if I steal your desktop's hashed password list, I can't use that to break into your system (not easily) because you need to know the actual passphrase (not just the hash) to authenticate. With WPA-PSK this is not the case, but it's the risk everyone accepts when they use it.
The PSK is not the passphrase; it is a deterministic transformation of the passphrase, much like the way passwords on your local system are stored. Why is this distinction important? Well, for one the PSK is much less susceptible to dictionary-style brute-force attacks than the passphrase it is derived from. Second, if your key becomes compromised, you can do something as simple as changing the SSID, and that will generate a sufficiently different key without needing to change the passphrase.
So, the answer to the original question in this thread, "How do you securely share the wi-fi password with your contacts?" is "You don't, directly. You share the PSK, because that is all that is stored locally on your client." And the reason that works is because the way your computer authenticates locally with a password database is fundamentally different from the way your client authenticates with your AP.
Did you read my comment? The key is derived from the passphrase, it is not the passphrase itself. Neither the key nor the passphrase is ever transmitted. There is a handshake protocol where both the AP and the client demonstrate they both know the key and then a unique session key is generated from the key to encrypt traffic.
I was curious about this too. But the AC below gave a nice hint, so I went looking for a better explanation. Here is the blurb from the Wiki,
Also referred to as WPA-PSK (Pre-shared key) mode, this is designed for home and small office networks and doesn't require an authentication server.[9] Each wireless network device encrypts the network traffic using a 256 bit key. This key may be entered either as a string of 64 hexadecimal digits, or as a passphrase of 8 to 63 printable ASCII characters.[10] If ASCII characters are used, the 256 bit key is calculated by applying the PBKDF2 key derivation function to the passphrase, using the SSID as the salt and 4096 iterations of HMAC-SHA1.[11] WPA-Personal mode is available with both WPA and WPA2.
So it seems the PSK can be passed around without revealing the passphrase. But if I also remember correctly, the PSK is supposed to rotate (or maybe that's WPA2).
It's not built in, but it is integrated. Just use zfs set sharesmb=on pool/srv
If you are having perms issues, make sure you have acl support enabled in your kernel and userland, and then use the aclinherit property on your zfs pool. Samba should handle the translation between NT and posix ACLs seamlessly, but you may need to use Samba4 for the best results.
There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.
I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.
In other words, there is a non-zero chance that you will get silent data corruptions on disk if you don't use ECC RAM. It is the same risk with ZFS as with any other filesystem. And yet, personal computers have been running without ECC RAM for decades and it hasn't been a travesty. So yeah, if you are running in the type of situation where you absolutely must ensure the highest level of data integrity, then you must use ECC RAM. If you are running your own personal home media NAS, it is probably not an unmitigable risk to buy cheaper hardware. The storage gurus will argue, "Why use ZFS if you don't care about it's data integrity features?" My response is that ZFS has a ton of other very useful features that make it a great filesystem.
BTW, bad vs. good RAM is not the same thing as non-ECC vs. ECC RAM. While ECC RAM will protect you from bit flips, a bad stick of RAM is still a bad stick with or without the extra parity bit. Aaron Toponce has a good (non-sensational) discussion on the topic, https://pthree.org/2013/12/10/...
Slashdot Mirror
How much of a salary premium is the question. Software developers at their current average pay, are comparable to other highly trained professionals (enginnering, lawyers, doctors, researchers, etc). How much more do you think they need to make? How much do you think is sustainable for a company to pay? Remember that you aren't talking about one or two individuals, but in some cases upwards of 2/3 of the entire workforce at a company.
If bumping salaries by 20-25% was all it took, they would probably do it. But for companies like Google, it is not a small subset of salaries, it is the majority of their workforce.
Companies don't deserve to exist, but if they don't exist there is nobody to employ you or make products for you to buy. Not every company is a Google-size monolith. There are quite a few that barely stay in the black each quarter. I'm not saying companies should be given a free reign to do whatever they want, just that discussions like this on \. are very one-sided. There are multiple viewpoints to consider and consequences to every course of action that must be weighed for pros and cons.
Right. The complaint by companies and hiring managers is that, even by paying 3x the average annual wage, they aren't able to find qualified people. So instead of A) trying to pay 5x the average annual wage which would not likely be sustainable for the company, or B) not hire anybody and not be able to grow the company or stay competitive in the market, they are opting for C) hiring H1-B workers (which the law requires to be paid at least the prevailing wage). It seems like a pretty clear situation to me. The job market for software developers is excellent, because IT demand is continuing to grow tremendously, and it isn't likely to change any time soon, but that doesn't mean there are infinite resources available to allocate to paying for IT salaries.
Uh, huh. Why yes, clearly instead of paying someone a paltry $100,000/yr they should raise the pay to $500,000/yr. I mean companies are rich, right? They can afford to pay their entire workforce salaries that fall in the top 1% income bracket nationally. For Google, this would only be about $26 billion dollars. No sweat.
The H1-B program is not for local worker shortages "No good candidates in Silicon Valley", it's for NATIONAL shortages as in "No qualified workers in the United States".
I love this completely one-sided viewpoint so prevalent on \. First of all, a shortage doesn't mean none, it means fewer than able to meet demand. Second,
Then by definition you were not paying competitive rates.
In May 2012, the median annual wage for all workers was $34,750, and the median salary for a software developer was $93,350 per year! That's from the Bureau of Labor Statistics. I know it's popular on \. to not care about the ability of a company to start, grow, or even sustain itself...but when you have to pay 3x the average salary for labor, and unemployment rates are less than the national average, and companies are faced with either hiring incompetent workers or increasing their offer to 4x or 5x the national average (still not guaranteeing that they will be able to hire someone qualified), there is a shortage, and that is what the H1-B program is intended to address.
Macrogen up in Korea has the highest certifications available - better than CLIA in terms of raw data quality - guaranteed to be as good as if Illumina did the sequencing for you itself. And they offer 30X whole genome for $1,000 (an extra $100 to extract the DNA from saliva). They also offer combined whole genome and 100X exome for $1,500.
Right, sure, go ahead and send your sequencing to Korea. What is the cost to have it done by MacrogenUSA, the subsidiary that can actually do FDA-approved work? $1000 doesn't even cover the cost of the materials, so who knows what they are pulling to advertise that.
But 23andMe was pure speech - there weren't offering anything physical - only information.
The issue is, what do people do with that information? If they run out and start seeking a bunch of new age remedies for perceived ailments because they don't understand enough about genetics to know what they are looking at, then it can be a real public health problem. Just look at vaccines. Jenny McCarthy wasn't even selling information, she was just giving it away for free, and it panicked enough people that they made some really dangerous decisions affecting their children and other people around them.
There is no tangible difference between "doing something physical" and "doing something on the internet." A genetic counselor doesn't do anything physical. They just talk to you. But they still have to be licensed to operate in their official capacity.
And getting back on topic, 23andMe was focused on just that problem: putting together a website that could help ordinary people understand their genomes. And the FDA shut them down
The FDA requires analytical verification ( does the test or service accurately and reproducibly provide the data that you are saying within acceptable margins of error? ) and clinical validation ( can the results of the test or service be reliably associated with specific health outcomes, after accounting for statistical significance and effect sizes? ) for medical devices and services sold in the USA. 23andMe has to go through this process as does every medical services company. This is not a conspiracy. The interpretation of medical data is not completely straightforward and requires a fair amount of expertise. Drug companies and device manufacturers like to whine about the FDA because they want the freedom to sell their snake oil to the public, but if you want medical decisions based on the careful consideration of the available science and not emotional manipulation, what the FDA does is essential.
The problem is that it takes quite a bit of expertise to use all of these tools. It's a lot like Linux in the early days before easy to install Linux "Distributions"
No, it is not like that at all. If it were a simple matter of an easy to execute set of programs, those tools would have been written a long time ago. There are, in fact, plenty of easy to use tools out there already. The challenging part is the nuance and interpretation of the data: understanding the error rates and data biases, knowing how to look for things like structural variation, understanding different types of mutation and how they may affect downstream processes, knowing how to verify your data and determine whether the result is trustworthy. With genetic data there is the additional aspect of inheritance. Probability is inherent to the interpretation of most of analyses; a straightforward yes or no is much less common. It takes many years of study and experience to get to this level. Some analyses are straightforward enough to be automated, but not all of them. Which is why we aren't going to get rid of doctors any time soon.
The 'raw' data they supply isn't really raw at all, but a processed list of several hundred thousand variant calls:
No, but it is cheap, which is not to be underestimated. If we want affordable healthcare, we have to care about cost and not just the new shiny. The other thing is, focusing on select variants allows them to do a targeted analysis. In a world plagued by systems biology, people like to think a "global picture" is always better, but having some idea what you are looking for before you start collecting data makes your statistical analysis, you know...meaningful.
At this point, SNP genotyping is pretty much obsolete for health-related uses because you can now get a full genome sequence for about $1,000 from just a few drop of saliva
No way. Two lanes of HiSeq (the most economical method) will net you about 10X coverage (assuming uniform coverage, which you won't get) for about $3000 at academic prices. For SNP calling, 20-30X is usually considered the minimum, with 50-60X being preferred. And then there is still the cost of DNA isolation, library prep, QC to factor in. The $1000 (human) genome is still quite a ways away.
SNP genotyping can still be useful for detecting losses or duplications of large parts of a chromosome ("structural" variations)
Maybe you are just being lazy with your terminology, but SNP genotyping, by definition, does not look for structural variations. SNP == single nucleotide polymorphism. There are separate arrays to look for these variations, but they are not SNP arrays. That said, while whole genome data might be better suited for this type of analysis, it is far from trivial. Usually targeted amplification of specific loci is used, not whole genome data. There is a tendency to believe that more data is always better, but genome data is not easy to understand. If you ever thought pharmaceutical research was sloppy due to poor statistical analyses and over interpretation of results, multiply this by 1000 for genome studies.
But the head of the FDA at the time was a medical doctor herself - so she was sympathetic to that view point even if it was not supported by the science.
I partially agree, but there is quite a bit of disagreement in the field about how significant these associations are and how meaningful they are with respect to medicine. It is easy to scare people and then use that to sell medications or treatments that may or may not work, so going through experts that have studied extensively and remain up-to-date in the field is good, in my opinion. Lots of people try to self-diagnose from websites already. I don't think that is leading to better healthcare outcomes. If you are worried about people who just want to make some quick cash, I would worry more about all of the companies selling tests and devices than I would about the doctors themselves.
Hanford was the site of the first nuclear reactor of its design, used to produce plutonium during WWII. The site was subsequently expanded to produce more plutonium, and some energy, through the Cold War. It is so messed up because of a lot of crap that went on during that time period: not knowing anything about industrial nuclear reactors, not having any kind of waste storage or processing plan, lots of scale-up, Cold War secrecy, etc. So, yeah, Hanford is a mess, but I think it is wrong to inhibit any kind of progress due to problems that were mostly documented more than 40 years ago. No waste was shipped to Hanford. The current DOE is very aware of the problems at Hanford and is actively trying to clean it up, but it takes a lot of time...and you need somewhere to store the waste. Without a waste storage facility, there is no way to clean up Hanford, and the barrels are going to keep leaking because most of them are more than 50 years old (never intended to be long-term waste storage).
It is not a Nature or Science paper because it is just a standard target enrichment library. They've been doing this for a long time to profile things like cancer markers, disease panels, etc. These guys just made a library to target viruses. That's all. It can do both RNA and DNA because they do a reverse transcriptase reaction first (required anyway to sequence RNA), and then pull down the resulting cDNA along with DNA and sequence it. Kind of cool, but not really groundbreaking.
Those desiring the change are the ones that need to explain why the change is needed/desirable in the first place.
They have, many times and in different places. If you didn't know that, maybe you should do some research.
I said that the arguments typically presented were weak and unreasonable.
So you do know that arguments and rationale have been made. Ok, how about a substantive counterargument then. Preferably one that actually addresses the arguments given and doesn't just dismiss them as "weak and unreasonable."
The ridiculously common command line that you wrote above fails on many/most distros that have chosen systemd as a default. These systems have no syslog at all.
Every distro that I know of (Red Hat, CentOS, Debian, Ubuntu, Arch) currently installs syslog alongside journald. If you don't have syslog installed, install it, and take it up with your distro for not including it. What your distro decides and decides not to bundle is not the fault of systemd.
Installing syslog on such a system doesn't log systems messages unless you reroute all of them away form systemd/journalctl.
Newsflash: you cannot have two logging daemons listening on the same socket and receiving the same system calls. If you want two logging daemons, one will need to forward that information to the other. JournalD does this, syslog does not, hence the current arrangement where journald forwards logging information to syslog.
But, do carry on insinuating that my log usage or viewing habits are inferior or inadequate because they use the preferred methods of the last 20+ years, rather than your preferred and totally new method. While we're at it, how about the fact that the log file itself is now formatted differently and is binary encoded rather than text. No, that doesn't break anything, 'except old people stuff'.
Wow, defensive much? Whether or not they are inferior or inadequate depends on what you are doing. They are for some people, and journalctl is the solution. If you don't want to use it, that's your choice. Do continue using your method of 20+ years, but you will be missing out on the advantages that journald provides.
As for dependencies, log dependencies are broken, despite your childish refrain of veiled insults. Startup scripts are broken. and the list of broken projects/packages/scripts goes on and on.
If there is a new init system, then old init scripts will be have to rewritten to use it. There is a compatibility method to ease the migration, but a migration will still be necessary eventually. I'm not sure why this is so shocking to you. Your argument basically boils down to "systemd is bad because it isn't sysvinit." If you don't see why that is a ridiculous argument, I don't know what else to say.
These facts aside, you're still arguing with insults.
I am not doing that at all. I am explaining to you how systemd works. You are the one taking it as an insult.
You're not presenting arguments that demonstrate any actual value of the new system/way.
Why do I need to present the arguments in favor of systemd, again, when they have already been made repeatedly elsewhere? At any rate, systemd advocacy is not the purpose of my reply. I am just explaining to you how it works and dispelling the myths that you are perpetuating.
All you've said, like I claimed in the GP, is that my 'unwillingness to accept the new way is because I'm inadequate in my use of Linux and that real users like yourself need all this old shit gone because it's old'.
Nowhere did I say anything like that.
I still say that this is not a valid or logical reason.
It's a good thing that is not one of the reasons then. There is a pretty good summary here (since you insist),
https://wiki.debian.org/Debate...
You are all completely fucked, and clearly show your lack of maturity and competence.
What an odd statement.
Look AC, learn something about the way the linux kernel works, and then maybe you will be able to understand the problem. There can only be one logging daemon attached to /dev/log. If it is journald it is journald, if it is syslog it is syslog. If you want both, one has to forward information to the other, and the amount and speed by which that forwarding can take place (via sockets) is limited by the kernel. So syslog missing messages that journald forwards, is an inherent limitation of the system and not the (direct) fault of journald. Since all of the logging information (more than syslog collects on its own) is there in the journal, and you just have to learn one command to get at it (journalctl), it is not seen as the travesty it is made out to be by the anti-systemd crowd.
Well, if you understood anything about the project, you would know that rebuilding the init system and rebuilding the log system are two separate projects. There are independent rationales for each of them. You are free to disagree, of course, but they exist. And a counterargument of "it works for me" is less than useless in a discussion about whether the change is necessary. Given that there are a lot of people who do think a change is necessary, you should make a better attempt to understand why and make a more substantive counterargument. Saying "Red Hat is an abomination" is not an argument.
Nor does it mean that the commands for accessing and controlling the system log needs to be abruptly deprecated
cat /var/log/syslog | grep
has not been deprecated. If that is the extent of your log analysis, it still works just fine. Just know that, in that case, you are getting the log information from syslog, not from journald, and there are inherent limitations to the forwarding mechanism that journald uses to share logging information with syslog. If you want to have complete access to all of the logging that journald does, you need to use its own interface, journalctl. It is really that simple and does not require a tremendous effort.
Nor does it mean that breaking many dependencies is acceptable.
No dependencies have been broken. If your log analysis tools require grep scraping a text log, they need to be rewritten to take full advantage of the data that journald provides. That is not a broken dependency. That is the normal course of software development that occurs when underlying system components are changed.
That's not to say the OS can't change, but the new pieces must be backwards compatible
Sure. But the limitation here is not with systemd, but the fact that systemd has to communicate with syslog through a socket, and the socket has a limited buffer for storing queued messages. So if you need critical, timing-dependent log messages, you really need to use journalctl. If you refuse to use journalctl then you are shooting yourself in the foot and complaining that it hurts.
He doesn't know how to use journalctl and doesn't want to learn. He just wants to grep syslog the same way he has done for 30 years.
No, but it is in the areas that matter to most people. The thing is, people (at least the people I know) don't spend a lot of time working on older documents. They are working on new documents. And when they upgrade their Office version, usually everybody is upgrading their Office version, so Office 2003 vs. Office 2013 incompatibilities don't matter to very many people. But there is no LibreOffice version that will import a complex Word document of any version without some major flaws (minor flaws are usually ok). Floating figures that move around or disappear, captions that disappear, tables that get mangled, line art that doesn't render or renders incorrectly.... If you are writing a simple office memo, LibreOffice works perfectly fine, but many people use it to do complex formatting, and for those people the incompatibilities are a big problem.
There is perfect and then there is perfect. It is true, Microsoft Office compatibility is the last major remaining issue that most of the people I talk to care about. They will even use LibreOffice on Windows, they love the idea of LibreOffice, but Microsoft Office file formats are the currency of document exchange among many academics. It is usually not things like font substitution that matter to them, though. It is tables, charts, floating figures, line art, 3D arrows, OLE objects, etc. If the margins are bit off when you send a document to somebody, no big deal, but if the table with the latest data in a progress report to the NIH doesn't show up or gets mangled, that screws the pooch. LibreOffice is really close, but it is that last 1-2% that is really critical for many people to switch. OOXML has made this process a lot easier, but it is still a beast of a file format.
Um, sure ok, if you want to think about it that way. I see what you are saying, but the question relevant to the discussion is "How do you share a passphrase when its only representation on the system is as a hashed key?" That is the question that started off the whole discussion. For example, if I steal your desktop's hashed password list, I can't use that to break into your system (not easily) because you need to know the actual passphrase (not just the hash) to authenticate. With WPA-PSK this is not the case, but it's the risk everyone accepts when they use it.
Ok, since you are the second person to say this, I guess I was unclear. The way PSK works in WPA when you use a passphrase is:
(passphrase + SSID) * hash algorithm = pre-shared key (PSK)
The PSK is not the passphrase; it is a deterministic transformation of the passphrase, much like the way passwords on your local system are stored. Why is this distinction important? Well, for one the PSK is much less susceptible to dictionary-style brute-force attacks than the passphrase it is derived from. Second, if your key becomes compromised, you can do something as simple as changing the SSID, and that will generate a sufficiently different key without needing to change the passphrase.
So, the answer to the original question in this thread, "How do you securely share the wi-fi password with your contacts?" is "You don't, directly. You share the PSK, because that is all that is stored locally on your client." And the reason that works is because the way your computer authenticates locally with a password database is fundamentally different from the way your client authenticates with your AP.
Did you read my comment? The key is derived from the passphrase, it is not the passphrase itself. Neither the key nor the passphrase is ever transmitted. There is a handshake protocol where both the AP and the client demonstrate they both know the key and then a unique session key is generated from the key to encrypt traffic.
I was curious about this too. But the AC below gave a nice hint, so I went looking for a better explanation. Here is the blurb from the Wiki,
Also referred to as WPA-PSK (Pre-shared key) mode, this is designed for home and small office networks and doesn't require an authentication server.[9] Each wireless network device encrypts the network traffic using a 256 bit key. This key may be entered either as a string of 64 hexadecimal digits, or as a passphrase of 8 to 63 printable ASCII characters.[10] If ASCII characters are used, the 256 bit key is calculated by applying the PBKDF2 key derivation function to the passphrase, using the SSID as the salt and 4096 iterations of HMAC-SHA1.[11] WPA-Personal mode is available with both WPA and WPA2.
So it seems the PSK can be passed around without revealing the passphrase. But if I also remember correctly, the PSK is supposed to rotate (or maybe that's WPA2).
Same here.
zfsonlinux doesn't have built in CIFS export
It's not built in, but it is integrated. Just use
zfs set sharesmb=on pool/srv
If you are having perms issues, make sure you have acl support enabled in your kernel and userland, and then use the aclinherit property on your zfs pool. Samba should handle the translation between NT and posix ACLs seamlessly, but you may need to use Samba4 for the best results.
I don't disagree with anything you have said. We use ECC RAM in our servers. My contention was only with the statement,
Not just a lot of RAM, it MUST be ECC RAM for ZFS
implying that ZFS is somehow a special case from other filesystems. It's not.
I'll go with one of the co-architects of ZFS, Matthew Ahrens,
http://arstechnica.com/civis/v...
There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.
I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.
In other words, there is a non-zero chance that you will get silent data corruptions on disk if you don't use ECC RAM. It is the same risk with ZFS as with any other filesystem. And yet, personal computers have been running without ECC RAM for decades and it hasn't been a travesty. So yeah, if you are running in the type of situation where you absolutely must ensure the highest level of data integrity, then you must use ECC RAM. If you are running your own personal home media NAS, it is probably not an unmitigable risk to buy cheaper hardware. The storage gurus will argue, "Why use ZFS if you don't care about it's data integrity features?" My response is that ZFS has a ton of other very useful features that make it a great filesystem.
BTW, bad vs. good RAM is not the same thing as non-ECC vs. ECC RAM. While ECC RAM will protect you from bit flips, a bad stick of RAM is still a bad stick with or without the extra parity bit. Aaron Toponce has a good (non-sensational) discussion on the topic,
https://pthree.org/2013/12/10/...