Why? That has been the standard way to do what you are trying to do on linux since forever. The way installers, like the Ubuntu installers, work under the hood is 1) they format the disk, 2) they set up a staging area, and 3) they install everything the system needs using the package manager. Afterward they will do some initial config to get the system to boot. The package manager will only install files that belong to its packages. So it won't 1) delete or empty directories that have already been created, or 2) overwrite or delete files that don't belong to it (ie: user-created files). Config files that have been modified from their defaults will be overwritten, but in many cases there is a *.d/ directory that allows you to put in custom config that won't get overwritten when you update or reinstall. That's why things like network interfaces are preserved when you update, because the interface configs are written into a.d/ directory, allowing the package-owned config file to be upgraded without wiping away the interfaces.
So to do a safe reinstall, the instructions are accurate. Tell the installer not to format the disk, use the same partitions that were already in place, and that's it. It is actually a very well designed system. If I anticipated needing to do this frequently, the only thing I might do is keep/home on a separate partition (and maybe/usr/local depending on how much I use it) so that I would be able to format the root partition safely. But like I say, not necessary to safely reinstall without losing your files.
For that matter, the machine would not be producing the drugs, it would just be packaging them
That was my reaction (no pun intended!) too at first, but no, this is actually chemical synthesis from starting materials. It is not quite as modular as they imply from the summary. You need to clean and restandardize the system to change product. But the idea is that it is capable of following a programmed synthesis and purification strategy. The purification is actually the coolest part to me. The synthesis uses an optimized flow chemistry design (think no solvents, short reaction times, high temperatures and pressures), but this is fairly standard process chemistry. The purification is the complicated part because the machine has to do liquid partitioning, column purification, and multiple recrystallization steps without human monitoring. And it has to meet USP standards for quality control at the end. That is really cool. There was some serious engineering that went into it, so even though it has somewhat limited applicability right now, it is an impressive feat.
That said, I'm not sure where this really fits. I can't think of many situations where you would benefit from on site synthesis. Remember, you would still need to preselect which drug you want to synthesize ahead of time and have all of the materials ready to go. And it would still take anywhere from 1-3 days start to finish. So in a hospital where you might work with hundreds of drug formulations, which ones are you going to maintain this system for? And is it really easier to synthesize on site as opposed to just managing shipments from manufacturing facilities? It might be able to help in the case of manufacturing shortages, but that seems like it would be a fairly rare occurrence....
It's really the cost of the pharmacy that's inhibiting this, not the drug manufacturing. Compounding pharmacies were essentially the genesis of the profession, but it takes expert skills and knowledge, and is not a high throughout process. So it doesn't fit in with the fast food delivery system for drug dispensing that we use now. There are still some compounding pharmacies around for special niche cases, but outfits like cvs stick with very standardized methods and procedures so that they can hire a skeleton staff to just crank through prescriptions at a high rate per hour. The other side of a pharmacists work (drug counseling and advice) is completely neglected because if you don't meet prescription quotas you get in trouble. In-patient pharmacies aren't much better anymore because hospitals are doing the same thing, they go for patient volume and number of procedures over actual outcomes. So, crank through IVs and narcotics so that you can do more surgeries and other procedures faster. Anything custom, even if it's better for the patient, is avoided because it slows you down.
I'm surprised a standard user would have the required security permissions to alter the MBR.
That's Windows security for you. Decades of established security practices where everyday users run unprivileged and only become root for administrative tasks, plus very user friendly implementations by Apple for OS X that nobody has complained about AFAIK, but nope, Microsoft has to come up with UAC instead. It is an improvement over XP, but it is still far too easy to inadvertently hose your system. The first thing I do when I install Windows is create an unprivileged user and set a password for the administrator. This instantly gets rid of 99% of the problems. The remaining 1% is training users when it is appropriate for an application to be asking for admin rights (almost never), but if you tell them to just never enter their password unless they are making a deliberate change to their system, or to ask if they are unsure, this is usually sufficient. I've never had malware problems on the boxes I administer.
After the payload file has been downloaded from a link, it will ask for elevation of privilege from the user. That file has a shield icon, so users expect the Windows User Account Control to be triggered. Unsurprisingly, they open it and give it permission, as they don’t suspect that this is a Trojan horse containing the payload for the Petya ransomware.
This is unbelievably stupid. I know, social engineering and all, but why the f$#%k would you click ok to a UAC warning to read a CV?! Cryptolocker I could understand because it just used the current user's credentials, but there is no excuse for getting infected by this.
I'm pretty sure you would need to at least pass the UAC panel on Windows as well. I can't believe Windows would allow access to the MBR without permissions. So how does this really work?
All kinds, really. Sometimes fatal errors because it wants to use shm or gvfs, neither of which works over a network. Or other assumptions - here are a couple from Gnome 2 (I don't have a Gnome 3 system nearby, because it just doesn't work for me):
Works for me with Gnome 3. It's laggy as hell, but that's X forwarding for you. Haven't used Gnome 2 in so long I have no way to test it. Your errors look like some kind of library conflicts are going on. Is the desktop on the remote machine fully functional on its own?
Try doing an xkill and click one window. Unless things have changed, boom, all of them go. Not good.
Right-click launcher, select "New Window."
New Terminal does what you describe while New Window gives you a separate process.
Or try entering "gedit.bashrc" from two different terminals (or run prompts). Where's the second window?
Same with gedit. To do it from the command line use gedit --new-window or gedit -s.
There are security implications too (connecting from multiple gnome-terminals to multiple servers give each destination a venue to attack not just the client machine but the other servers).
Virtually by definition, ALL system crashes HAVE TO BE in the kernel.
Um, ok. I wasn't being pedantic enough. The majority of crashes on Linux distributions that disturb the end user are not caused by the kernel. Meaning, userspace programs crash all the time and this bothers the end user, whatever they may have actually been doing with their system. A daemon locks up and you have to restart it or something, fine ok, not technically a "crash" but still annoying to the end user. How often do true kernel crashes happen relative to userspace program crashes? Small. Maybe a bit higher if you include the crashes caused by blobs.
I'll give you an example of how busted the linux kernel is. I've been bitten so many times by the system bogging down horribly from swapping
I can't imagine what you must be doing then. Unless you are constantly running at complete memory saturation, in which case swapping is exactly what the system should do. You can adjust the swappiness of the kernel using/proc/sys/vm/swappiness.
Surely, processes will just core dump if it hits the wall then, right?
That depends on how you turned off swapping. If you used the swappiness tunable, this does not completely eliminate swapping. To do that, use swapoff -a. Depending on what is exactly going on in your case, you may also need to set/proc/sys/vm/overcommit_memory.
This is just STUPID. It is a bloody INSANE design.
Well, it really depends on your perspective. In the case of Linux, it tries really hard to honor the request, even if it stretches the memory to maximum utilization. More processes, more constant disk and cpu usage = more mileage out of your hardware. Interactivity sucks, of course, due to latency issues. But that is not inherently bad, just bad for the situation where you prefer latency over throughput. Thankfully, most of the parameters that affect latency, like preemption, are tunable. So you can tailor your system to suit your needs if you put some effort into it.
That said, I frequently max out the memory on my system and never run into the problems you are describing. At least nothing I can't fix by switching to a text console and killing something. So if you intend to do that frequently, you might need to spend some time tuning and/or recompiling your kernel, because the defaults are clearly not working for your situation.
Ok, let me rephrase. Show me a working, performant, general purpose microkernel. L4 and QNX are nice, but do you have an example of their use outside of the embedded space? To replace Linux, it will need to run well not just on desktops, but a variety of servers and networking hardware, and it will need to be able to scale to large CPU and memory mainframes. Context-switching overhead has always been the argument against microkernels. Take QNX, for example, from the Wiki:
If the receiving process is waiting for the message, control of the CPU is transferred at the same time, without a pass through the CPU scheduler. Thus, sending a message to another process and waiting for a reply does not result in "losing one's turn" for the CPU. This tight integration between message passing and CPU scheduling is one of the key mechanisms that makes QNX message passing broadly usable. Most Unix and Linux interprocess communication mechanisms lack this tight integration, although a user space implementation of QNX-type messaging for Linux does exist. Mishandling of this subtle issue is a primary reason for the disappointing performance of some other microkernel systems such as early versions of Mach.
Ok, sounds interesting. But then:
All I/O operations, file system operations, and network operations were meant to work through this mechanism, and the data transferred was copied during message passing. Later versions of QNX reduce the number of separate processes and integrate the network stack and other function blocks into single applications for performance reasons.
So basically, despite their fancy message passing design, to get performance they have to lump everything together into gigantic monolithic applications, albeit running in userspace. Doesn't sound like a great proof-of-principle design to me.
seL4 certainly looks very interesting and can have some good uses, but I would like to see something other than just IPC benchmarks before believing that the performance issues of microkernels has been solved.
While I generally like the idea of new people coming up with new projects and hacking away, the linked documentation reads like flamebait and doesn't have much in the way of substance. Some of their contentions are rather strange. For example,
There are numerous other OS's, kernels, whatever that lack for contributors, and are in desperate need of more coders. Many times, this is for a good reason. Failures in management, a lack of money, inspiration, or innovation, or a limited set of applications have all caused projects to dwindle and eventually fail.... Take Linux for example:
Ok, let me stop you there. Linux is not a perfect project by any means, but you can hardly say that it is mismanaged, uninspired, or lacking in innovation or money. It had 4000 contributors over about a 1 year period, and 12,000 over a 10 year period. It runs on everything from embedded systems to big iron mainframes and balances the often conflicting needs pretty well, in my opinion. Of all the things you can say about Linux, it does not lack in number of contributors or vitality of the project.
Legacy until infinity: Old syscalls stay around forever, drivers for long-unbuyable hardware stay in the kernel as a mandatory part.
Uh, yes. Because, shocking I know, quite a bit of hardware out there still depends on that code. And anyway, as long as somebody is there to maintain it, who cares if it is old. Admittedly, there is some cruft in the kernel. It's an old project, so I think it is natural to expect that. But at the same time there are people working on it and trying to keep the codebase modern.
While they can be disabled, running them in kernel space is essentially unnecessary, and is, by far, the biggest source of system crashes, security issues, and unexpected bugs.
I'll need a citation for that one. I won't dispute that old code has occasionally caused bugs and crashes, but the statement is hyperbole. The majority of crashes on Linux distributions have nothing to do with the kernel at all. Of the ones that do, it usually has something to do with the binary blobs used to run graphical hardware, which is certainly not old code.
Huge codebase: To contribute, you must find a place to fit in to nearly 25 million lines of code, in just the kernel. This is due to Linux's monolithic architecture.
Hurray, this useless debate continues. I'll tell you what. Show me a working performant microkernel (no, XNU is not a microkernel) and I'll concede you have a point. Until then, it is just useless chatter. As to their point, just because the kernel architecture is monolithic doesn't mean the codebase isn't organized. One can in fact easily work on something like a filesystem without touching the network code, for example. Linux has had separate subsystems maintainers since at least 2003.
Restrictive license: Linux is licensed under GPL2. More on this in Why MIT?.
Non-sequitur to say the least. While commonly debated on Slashdot, really doesn't contribute anything useful to the discussion.
Lack of memory safety: Linux has had numerous issues with memory safety throughout time. C is a fine language, but for such a security critical system, C doesn't fit.
This is really the only interesting thing they have said, but not a lot of detail on what they mean other than that they think the whole kernel should be reimplemented in Rust. Well, let's see how that goes. Check back in what, 5 years?
Compared to BSD, Linux is completely frontal-lobe-missing, in every imaginable way. The code base is one big, ugly hack, and the design is bad
Nope, it doesn't. PIN/PUK system has settings (number of pin tries, number of puk tries, as well as the puk itself) hard-coded in the chip. They cannot be changed by the user (although they probably can be changed by the network). While PIN/PUK is a good PIN verification sytem, it is not without limitations and its existence does not contradict anything I have said at all.
Well, I'm sure the same ignorance and stupidity is why Apple is in this mess in the first place. Try brute forcing the PIN on your SIM card some time and see how far you get.
Bear in mind that SIM cards are designed to hold a limited and very specific set of information. It doesn't hold the phone OS, for example. When you want to encrypt the whole device, and not just a part of it, this is not as easy a problem to solve as you are trying to imply.
But security should be guaranteed with a PIN. That is, if I configure my phone for three trials and use a 4 digit code, then I should be certain that the risk of someone unlocking the phone by trial and error is no more than 3:10000, short of someone actually modifying the innards of a secure processor.
As long as you are operating within the confines of the phone where the arbitrary restrictions on retries are being enforced, then yes. As soon as you can rip out the firmware and access the data directly, no.
Properly implemented PIN codes can't be brute forced, because you only get a small, limited number of tries.
No. The pin code can be brute forced, period. It is an inherent limitation of using them. Other weak passwords (dictionary based, etc) are also subject to the same limitation. The password checking software can make brute-forcing infeasible, but the brute-forcing vulnerability is still there if you can get around the software. The only passwords that can be guaranteed cryptographically secure are long alphanumeric strings.
The limit rules are still configurable by the user, they simply can't be changed until you have successfully unlocked the hardware.
I don't think you've thought this through. If pin checking is implemented in the silicon, not the software, it cannot be changed by the user, unless you include the ability to flash the firmware, and then we are back to the current situation.
My point is that if Apple can push such a software update to an existing phone without the user unlocking the device first, then iOS cryptography is broken already.
It's not about pushing an update to the phone (which does require the phone be unlocked), it is about using the firmware loader to flash itself, much like the way you can flash the BIOS on any PC if you have physical access (yes, even if a BIOS password has been set). The only feasible way to secure this is to encypt the loader itself and design a second loader that unencrypts the update loader, but it is not clear whether this level of complexity is allowed by the chip logic.
No, the real problem, that is not Apple's, is that the pin passcodes are trivially brute-forceable. If you really care about security, you have to guard against brute-force attacks, which you do by using a long alphanumeric password, not a pin code. Apple has done a great thing by trying to mitigate the brute-force vulnerability with their software lockout policy, but there is only so much they can do. There are only three ways out of Apple's current situation: 1) make the firmware completely unflashable, which is not desirable for a number of obvious reasons, 2) make the brute-force limiting rules in hardware instead of software, but then they wouldn't be configurable by the user, 3) eliminate the pin passcode and allow only alphanumeric passwords, which is probably the best option all things considered. But Apple doesn't actually need to force it. They just need to make it clear that security is not guaranteed with a pin passcode.
You keep missing the question. What does fsck repair that is not handled internally by zfs transactional writes? Answer: nothing. Repairing metadata inconsistency with zfs, in the worst case scenario, amounts to rolling back to the last successful transaction. There is no (offline) fsck tool because there is literally nothing else you can do to fix metadata inconsistency errors that would be better than that. Scrubbing is a part of filesystem maintenance, but it is really a different tool for a different scenario. It's my fault for bringing it up, but it is unrelated to fsck for the uses you seem most concerned with.
The vast majority of linux users don't raid their root disk, nor do they make regular backups
While most of the benefits of zfs are lost if you don't RAID, you can still benefit from transactional writes. I wouldn't set it up that way personally, though, since the whole point of zfs is to maintain data integrity. If you don't make backups, well good luck with that. Forget the filesystem for a moment and just consider the increasing prevalence of SSDs. They can fail completely suddenly and without warning, and recovering the data is no simple matter. So what are you going to do without backups if that happens to you?
The bottom line is, using ZFS on workstations for most users is just nuts
I wouldn't use zfs on a workstation. That seems rather pointless to me. That is not what the article is suggesting either.
You cannot recover from bad ext4 superblocks with fsck, so how is this any different from the equally unlikely scenario of a zfs bug resulting in an unrecoverable zpool? You can recover data from ext4 using low-level tools, yes, but I have no reason to believe you can't also do this with zfs if you are comfortable with the underlying filesystem structure and know where to look. Most people just don't bother because restoring from backup is easier.
why they should give up this safety net in the name of some psychobabble about how raid repair is just as good as fsck repair,
You missed it. Scrubbing is better than fsck, for certain types of repairs, namely the ones that fsck doesn't do. But hey, do what you want, I don't care. I personally use both ext4 and zfs for different purposes. It's better to be pragmatic than ideological in my opinion.
You have yet to explain what safety net fsck actually provides that isn't accomplished by zfs in another way. I gave you my analysis, let's hear yours.
Let's call it online block-level filesystem integrity checking and repair using a redundant copy if it is available. Simply saying it's "just a raid repair" understates what it actually does. With scrubbing, you can detect and fix silent data corruption, which is something you cannot do with traditional fsck.
it does not understand the structure of the filesystem and therefore is incapable of repairing inconsistencies
You will have to be more specific about what you mean. You are correct that it does not repair metadata inconsistencies, but that is because those are handled in a different way. The #1 thing fsck does for an ext filesystem is replay the journal upon a power-failure event. For zfs you don't need a fsck for this because the ZIL is replayed automatically every time the pool is activated. The #2 thing fsck allows you to do is manually repair inconsistencies that can't be restored by the journal. However, this is a mostly useless function as about the only thing you can do is delete orphaned inodes. You can get your filesystem mountable, but there is no way to verify what state the data is actually in afterward (did you just lose data, or did you merge some successful writes with some failed writes effectively corrupting your data?). With zfs, all writes are transactional. So if there is a metadata inconsistency that can't be repaired by replaying the ZIL, you just end up rolling back the whole transaction. You will lose new data, but you won't corrupt existing data.
Can you run into an obscure zfs bug that causes you to unrecoverably lose your entire pool? Yes, of course, which is why you need good backups in every case. But these aren't random inconsistency errors that one might expect to happen in any normal situation. If you were to corrupt the ext4 superblocks you would be just as screwed.
I looked at doing something similar, but FreeNAS now needs 8 GB of RAM.
Meh. I played around with FreeNAS for a while but wasn't too impressed. It makes some things easy. If the preconfigured setup does everything you need, great, but if you need access to more configuration options/customization (like I did), it's a pita. Just grab a copy of zfsonlinux and role your own. It's really not much more complicated than any other filesystem+lvm setup.
Yes, absolutely. However, the nanopore sequencer has to have more than one limited-applicability advantage for it to be commercially successful against competitors. Just consider seriously for a minute what has actually been described (not hyped about) in this paper.
1) A mobile lab in a suitcase including sequencer - yes, that's awesome
2) Deployed to a region experiencing an outbreak
- ok, can be useful, but how many outbreaks occur every year that actually benefit from on-site sequencing
- in the case of Ebola, which spreads and mutates quickly, the advantage may be very real, but Zika? the flu? not so sure
- is the advantage enough to offset the tremendous cost compared to alternatives?
3) They did sequence a segment of the viral genome (not the whole genome) and successfully call base mismatches
- but they didn't call indels
- they ignored homopolymer regions and the ends of their amplicons
- they did get some useful information, but there were samples that they couldn't successfully analyze after sequencing
So in the end, it is a sequencer that can be deployed to remote villages, provided you have a very limited set of analyses you intend to do, and you don't care about the cost. But is that enough to be commercially viable and displace competitors? I don't think so.
I'm not trying to rag on Oxford Nanopore, don't get me wrong. If they really could reliably sequence whole genomes fast and with minimal preparation from a usb stick, I would definitely jump on the bandwagon. I'm just tired of all the hype. They've been promising these breakthroughs for more than a decade now, but they have yet to deliver. Meanwhile other companies, namely PacBio, have appeared and been very successful at providing long reads at an affordable cost, so I'm not holding my breath for ONP.
though if necessary you could presumably do many additional passes to bring the error rate down further.
In its present state, not really. The biggest problem with nanopore data right now is systematic errors in homopolymer regions. These can't be easily corrected out with higher coverage. Incidentally, some of the most significant mutation events are in homopolymer regions, so this is bad.
but it's more than sufficient to recognize a virus.
Correct. But you need to know more. In particular, which strain of virus? Strain variations can easily be much less than 4%.
but so long as you're taking many samples from a community you can probably make a pretty high-confidence conclusion about even SNPs
If the errors were mostly random, you are correct. That is the problem here, the errors are systematic, not random, which is why they can't be corrected out with higher coverage. The good news, though, is that if you are looking at other types of mutations, like inversions or repeat expansions, that are easier to identify than SNPs, the error rate is probably good enough.
Not perfect, but a huge improvement over simply guessing at the path of infection.
You don't have to guess. You just have to use a different sequencing technology. Almost every vendor is trying to provide a rapid sequencing service for this exact reason. Illumina has MiSeq (12-24 hrs. run time), and PacBio is always fast (run time ~3 hrs) as is Ion Torrent (run time ~2 hrs). The biggest advantage that ONP has is portability, but if you need a lab (and an Internet connection) anyway to process samples, I'm not sure that this will really play out to their favor in the long run. ONP gets a lot of awe and excitement, which leads to a lot of hype, but not a lot of practical advantages.
Or maybe they're already doing that and accuracy plateaus at 96%
Yes, this is correct.
They're not trying to do genome-research class sequencing, they just need to identify the DNA strands of interest
Well, it does depend on what kind of downstream analysis they plan to do, but 96% is not great. That is 1 error per 25 bases. Good enough for alignment procedures to work, but definitely bad if you are looking for SNPs.
As one commenter on ONP has been stating for a while: what's the point of a portable sequencer if you have to haul around a full-size Illumina sequencer along with it to get the accuracy you need?
The nanopore's advantage in this example is the virus genome, which is a relatively small size, and a well-defined reference sequence. In its present state, the nanopore is mostly useless for larger, previously unsequenced, genomes on a cost/bp basis.
Um, bullshit. See, this has been the problem with Oxford Nanopore since the beginning. They distract and confuse through a lot of misleading statements and media hype, which is why I can't trust any of their claims. The typical accuracy of single-pass 1D reads on real data is about 70%, about 80% on 2D reads. The 96% accuracy they are quoting on their site is after they error-correct the reads.
Slashdot Mirror
Why? That has been the standard way to do what you are trying to do on linux since forever. The way installers, like the Ubuntu installers, work under the hood is 1) they format the disk, 2) they set up a staging area, and 3) they install everything the system needs using the package manager. Afterward they will do some initial config to get the system to boot. The package manager will only install files that belong to its packages. So it won't 1) delete or empty directories that have already been created, or 2) overwrite or delete files that don't belong to it (ie: user-created files). Config files that have been modified from their defaults will be overwritten, but in many cases there is a *.d/ directory that allows you to put in custom config that won't get overwritten when you update or reinstall. That's why things like network interfaces are preserved when you update, because the interface configs are written into a .d/ directory, allowing the package-owned config file to be upgraded without wiping away the interfaces.
So to do a safe reinstall, the instructions are accurate. Tell the installer not to format the disk, use the same partitions that were already in place, and that's it. It is actually a very well designed system. If I anticipated needing to do this frequently, the only thing I might do is keep /home on a separate partition (and maybe /usr/local depending on how much I use it) so that I would be able to format the root partition safely. But like I say, not necessary to safely reinstall without losing your files.
For that matter, the machine would not be producing the drugs, it would just be packaging them
That was my reaction (no pun intended!) too at first, but no, this is actually chemical synthesis from starting materials. It is not quite as modular as they imply from the summary. You need to clean and restandardize the system to change product. But the idea is that it is capable of following a programmed synthesis and purification strategy. The purification is actually the coolest part to me. The synthesis uses an optimized flow chemistry design (think no solvents, short reaction times, high temperatures and pressures), but this is fairly standard process chemistry. The purification is the complicated part because the machine has to do liquid partitioning, column purification, and multiple recrystallization steps without human monitoring. And it has to meet USP standards for quality control at the end. That is really cool. There was some serious engineering that went into it, so even though it has somewhat limited applicability right now, it is an impressive feat.
That said, I'm not sure where this really fits. I can't think of many situations where you would benefit from on site synthesis. Remember, you would still need to preselect which drug you want to synthesize ahead of time and have all of the materials ready to go. And it would still take anywhere from 1-3 days start to finish. So in a hospital where you might work with hundreds of drug formulations, which ones are you going to maintain this system for? And is it really easier to synthesize on site as opposed to just managing shipments from manufacturing facilities? It might be able to help in the case of manufacturing shortages, but that seems like it would be a fairly rare occurrence....
It's really the cost of the pharmacy that's inhibiting this, not the drug manufacturing. Compounding pharmacies were essentially the genesis of the profession, but it takes expert skills and knowledge, and is not a high throughout process. So it doesn't fit in with the fast food delivery system for drug dispensing that we use now. There are still some compounding pharmacies around for special niche cases, but outfits like cvs stick with very standardized methods and procedures so that they can hire a skeleton staff to just crank through prescriptions at a high rate per hour. The other side of a pharmacists work (drug counseling and advice) is completely neglected because if you don't meet prescription quotas you get in trouble. In-patient pharmacies aren't much better anymore because hospitals are doing the same thing, they go for patient volume and number of procedures over actual outcomes. So, crank through IVs and narcotics so that you can do more surgeries and other procedures faster. Anything custom, even if it's better for the patient, is avoided because it slows you down.
I'm surprised a standard user would have the required security permissions to alter the MBR.
That's Windows security for you. Decades of established security practices where everyday users run unprivileged and only become root for administrative tasks, plus very user friendly implementations by Apple for OS X that nobody has complained about AFAIK, but nope, Microsoft has to come up with UAC instead. It is an improvement over XP, but it is still far too easy to inadvertently hose your system. The first thing I do when I install Windows is create an unprivileged user and set a password for the administrator. This instantly gets rid of 99% of the problems. The remaining 1% is training users when it is appropriate for an application to be asking for admin rights (almost never), but if you tell them to just never enter their password unless they are making a deliberate change to their system, or to ask if they are unsure, this is usually sufficient. I've never had malware problems on the boxes I administer.
Found another article,
http://sensorstechforum.com/re...
After the payload file has been downloaded from a link, it will ask for elevation of privilege from the user. That file has a shield icon, so users expect the Windows User Account Control to be triggered. Unsurprisingly, they open it and give it permission, as they don’t suspect that this is a Trojan horse containing the payload for the Petya ransomware.
This is unbelievably stupid. I know, social engineering and all, but why the f$#%k would you click ok to a UAC warning to read a CV?! Cryptolocker I could understand because it just used the current user's credentials, but there is no excuse for getting infected by this.
I'm pretty sure you would need to at least pass the UAC panel on Windows as well. I can't believe Windows would allow access to the MBR without permissions. So how does this really work?
All kinds, really. Sometimes fatal errors because it wants to use shm or gvfs, neither of which works over a network. Or other assumptions - here are a couple from Gnome 2 (I don't have a Gnome 3 system nearby, because it just doesn't work for me):
Works for me with Gnome 3. It's laggy as hell, but that's X forwarding for you. Haven't used Gnome 2 in so long I have no way to test it. Your errors look like some kind of library conflicts are going on. Is the desktop on the remote machine fully functional on its own?
Try doing an xkill and click one window. Unless things have changed, boom, all of them go. Not good.
Right-click launcher, select "New Window."
New Terminal does what you describe while New Window gives you a separate process.
Or try entering "gedit .bashrc" from two different terminals (or run prompts). Where's the second window?
Same with gedit. To do it from the command line use gedit --new-window or gedit -s.
There are security implications too (connecting from multiple gnome-terminals to multiple servers give each destination a venue to attack not just the client machine but the other servers).
I have no idea what you mean by this.
Virtually by definition, ALL system crashes HAVE TO BE in the kernel.
Um, ok. I wasn't being pedantic enough. The majority of crashes on Linux distributions that disturb the end user are not caused by the kernel. Meaning, userspace programs crash all the time and this bothers the end user, whatever they may have actually been doing with their system. A daemon locks up and you have to restart it or something, fine ok, not technically a "crash" but still annoying to the end user. How often do true kernel crashes happen relative to userspace program crashes? Small. Maybe a bit higher if you include the crashes caused by blobs.
I'll give you an example of how busted the linux kernel is. I've been bitten so many times by the system bogging down horribly from swapping
I can't imagine what you must be doing then. Unless you are constantly running at complete memory saturation, in which case swapping is exactly what the system should do. You can adjust the swappiness of the kernel using /proc/sys/vm/swappiness.
Surely, processes will just core dump if it hits the wall then, right?
That depends on how you turned off swapping. If you used the swappiness tunable, this does not completely eliminate swapping. To do that, use swapoff -a. Depending on what is exactly going on in your case, you may also need to set /proc/sys/vm/overcommit_memory.
This is just STUPID. It is a bloody INSANE design.
Well, it really depends on your perspective. In the case of Linux, it tries really hard to honor the request, even if it stretches the memory to maximum utilization. More processes, more constant disk and cpu usage = more mileage out of your hardware. Interactivity sucks, of course, due to latency issues. But that is not inherently bad, just bad for the situation where you prefer latency over throughput. Thankfully, most of the parameters that affect latency, like preemption, are tunable. So you can tailor your system to suit your needs if you put some effort into it.
That said, I frequently max out the memory on my system and never run into the problems you are describing. At least nothing I can't fix by switching to a text console and killing something. So if you intend to do that frequently, you might need to spend some time tuning and/or recompiling your kernel, because the defaults are clearly not working for your situation.
Ok, let me rephrase. Show me a working, performant, general purpose microkernel. L4 and QNX are nice, but do you have an example of their use outside of the embedded space? To replace Linux, it will need to run well not just on desktops, but a variety of servers and networking hardware, and it will need to be able to scale to large CPU and memory mainframes. Context-switching overhead has always been the argument against microkernels. Take QNX, for example, from the Wiki:
If the receiving process is waiting for the message, control of the CPU is transferred at the same time, without a pass through the CPU scheduler. Thus, sending a message to another process and waiting for a reply does not result in "losing one's turn" for the CPU. This tight integration between message passing and CPU scheduling is one of the key mechanisms that makes QNX message passing broadly usable. Most Unix and Linux interprocess communication mechanisms lack this tight integration, although a user space implementation of QNX-type messaging for Linux does exist. Mishandling of this subtle issue is a primary reason for the disappointing performance of some other microkernel systems such as early versions of Mach.
Ok, sounds interesting. But then:
All I/O operations, file system operations, and network operations were meant to work through this mechanism, and the data transferred was copied during message passing. Later versions of QNX reduce the number of separate processes and integrate the network stack and other function blocks into single applications for performance reasons.
So basically, despite their fancy message passing design, to get performance they have to lump everything together into gigantic monolithic applications, albeit running in userspace. Doesn't sound like a great proof-of-principle design to me.
seL4 certainly looks very interesting and can have some good uses, but I would like to see something other than just IPC benchmarks before believing that the performance issues of microkernels has been solved.
While I generally like the idea of new people coming up with new projects and hacking away, the linked documentation reads like flamebait and doesn't have much in the way of substance. Some of their contentions are rather strange. For example,
There are numerous other OS's, kernels, whatever that lack for contributors, and are in desperate need of more coders. Many times, this is for a good reason. Failures in management, a lack of money, inspiration, or innovation, or a limited set of applications have all caused projects to dwindle and eventually fail. ...
Take Linux for example:
Ok, let me stop you there. Linux is not a perfect project by any means, but you can hardly say that it is mismanaged, uninspired, or lacking in innovation or money. It had 4000 contributors over about a 1 year period, and 12,000 over a 10 year period. It runs on everything from embedded systems to big iron mainframes and balances the often conflicting needs pretty well, in my opinion. Of all the things you can say about Linux, it does not lack in number of contributors or vitality of the project.
Legacy until infinity: Old syscalls stay around forever, drivers for long-unbuyable hardware stay in the kernel as a mandatory part.
Uh, yes. Because, shocking I know, quite a bit of hardware out there still depends on that code. And anyway, as long as somebody is there to maintain it, who cares if it is old. Admittedly, there is some cruft in the kernel. It's an old project, so I think it is natural to expect that. But at the same time there are people working on it and trying to keep the codebase modern.
While they can be disabled, running them in kernel space is essentially unnecessary, and is, by far, the biggest source of system crashes, security issues, and unexpected bugs.
I'll need a citation for that one. I won't dispute that old code has occasionally caused bugs and crashes, but the statement is hyperbole. The majority of crashes on Linux distributions have nothing to do with the kernel at all. Of the ones that do, it usually has something to do with the binary blobs used to run graphical hardware, which is certainly not old code.
Huge codebase: To contribute, you must find a place to fit in to nearly 25 million lines of code, in just the kernel. This is due to Linux's monolithic architecture.
Hurray, this useless debate continues. I'll tell you what. Show me a working performant microkernel (no, XNU is not a microkernel) and I'll concede you have a point. Until then, it is just useless chatter. As to their point, just because the kernel architecture is monolithic doesn't mean the codebase isn't organized. One can in fact easily work on something like a filesystem without touching the network code, for example. Linux has had separate subsystems maintainers since at least 2003.
Restrictive license: Linux is licensed under GPL2. More on this in Why MIT?.
Non-sequitur to say the least. While commonly debated on Slashdot, really doesn't contribute anything useful to the discussion.
Lack of memory safety: Linux has had numerous issues with memory safety throughout time. C is a fine language, but for such a security critical system, C doesn't fit.
This is really the only interesting thing they have said, but not a lot of detail on what they mean other than that they think the whole kernel should be reimplemented in Rust. Well, let's see how that goes. Check back in what, 5 years?
Compared to BSD, Linux is completely frontal-lobe-missing, in every imaginable way. The code base is one big, ugly hack, and the design is bad
I read the spec. Did you?
http://www.etsi.org/deliver/et...
Nope, it doesn't. PIN/PUK system has settings (number of pin tries, number of puk tries, as well as the puk itself) hard-coded in the chip. They cannot be changed by the user (although they probably can be changed by the network). While PIN/PUK is a good PIN verification sytem, it is not without limitations and its existence does not contradict anything I have said at all.
Well, I'm sure the same ignorance and stupidity is why Apple is in this mess in the first place. Try brute forcing the PIN on your SIM card some time and see how far you get.
Bear in mind that SIM cards are designed to hold a limited and very specific set of information. It doesn't hold the phone OS, for example. When you want to encrypt the whole device, and not just a part of it, this is not as easy a problem to solve as you are trying to imply.
But security should be guaranteed with a PIN. That is, if I configure my phone for three trials and use a 4 digit code, then I should be certain that the risk of someone unlocking the phone by trial and error is no more than 3:10000, short of someone actually modifying the innards of a secure processor.
As long as you are operating within the confines of the phone where the arbitrary restrictions on retries are being enforced, then yes. As soon as you can rip out the firmware and access the data directly, no.
Properly implemented PIN codes can't be brute forced, because you only get a small, limited number of tries.
No. The pin code can be brute forced, period. It is an inherent limitation of using them. Other weak passwords (dictionary based, etc) are also subject to the same limitation. The password checking software can make brute-forcing infeasible, but the brute-forcing vulnerability is still there if you can get around the software. The only passwords that can be guaranteed cryptographically secure are long alphanumeric strings.
The limit rules are still configurable by the user, they simply can't be changed until you have successfully unlocked the hardware.
I don't think you've thought this through. If pin checking is implemented in the silicon, not the software, it cannot be changed by the user, unless you include the ability to flash the firmware, and then we are back to the current situation.
My point is that if Apple can push such a software update to an existing phone without the user unlocking the device first, then iOS cryptography is broken already.
It's not about pushing an update to the phone (which does require the phone be unlocked), it is about using the firmware loader to flash itself, much like the way you can flash the BIOS on any PC if you have physical access (yes, even if a BIOS password has been set). The only feasible way to secure this is to encypt the loader itself and design a second loader that unencrypts the update loader, but it is not clear whether this level of complexity is allowed by the chip logic.
No, the real problem, that is not Apple's, is that the pin passcodes are trivially brute-forceable. If you really care about security, you have to guard against brute-force attacks, which you do by using a long alphanumeric password, not a pin code. Apple has done a great thing by trying to mitigate the brute-force vulnerability with their software lockout policy, but there is only so much they can do. There are only three ways out of Apple's current situation: 1) make the firmware completely unflashable, which is not desirable for a number of obvious reasons, 2) make the brute-force limiting rules in hardware instead of software, but then they wouldn't be configurable by the user, 3) eliminate the pin passcode and allow only alphanumeric passwords, which is probably the best option all things considered. But Apple doesn't actually need to force it. They just need to make it clear that security is not guaranteed with a pin passcode.
You keep missing the question. What does fsck repair that is not handled internally by zfs transactional writes? Answer: nothing. Repairing metadata inconsistency with zfs, in the worst case scenario, amounts to rolling back to the last successful transaction. There is no (offline) fsck tool because there is literally nothing else you can do to fix metadata inconsistency errors that would be better than that. Scrubbing is a part of filesystem maintenance, but it is really a different tool for a different scenario. It's my fault for bringing it up, but it is unrelated to fsck for the uses you seem most concerned with.
The vast majority of linux users don't raid their root disk, nor do they make regular backups
While most of the benefits of zfs are lost if you don't RAID, you can still benefit from transactional writes. I wouldn't set it up that way personally, though, since the whole point of zfs is to maintain data integrity. If you don't make backups, well good luck with that. Forget the filesystem for a moment and just consider the increasing prevalence of SSDs. They can fail completely suddenly and without warning, and recovering the data is no simple matter. So what are you going to do without backups if that happens to you?
The bottom line is, using ZFS on workstations for most users is just nuts
I wouldn't use zfs on a workstation. That seems rather pointless to me. That is not what the article is suggesting either.
You cannot recover from bad ext4 superblocks with fsck, so how is this any different from the equally unlikely scenario of a zfs bug resulting in an unrecoverable zpool? You can recover data from ext4 using low-level tools, yes, but I have no reason to believe you can't also do this with zfs if you are comfortable with the underlying filesystem structure and know where to look. Most people just don't bother because restoring from backup is easier.
why they should give up this safety net in the name of some psychobabble about how raid repair is just as good as fsck repair,
You missed it. Scrubbing is better than fsck, for certain types of repairs, namely the ones that fsck doesn't do. But hey, do what you want, I don't care. I personally use both ext4 and zfs for different purposes. It's better to be pragmatic than ideological in my opinion.
You have yet to explain what safety net fsck actually provides that isn't accomplished by zfs in another way. I gave you my analysis, let's hear yours.
Zfs scrub is just a raid repair
Let's call it online block-level filesystem integrity checking and repair using a redundant copy if it is available. Simply saying it's "just a raid repair" understates what it actually does. With scrubbing, you can detect and fix silent data corruption, which is something you cannot do with traditional fsck.
it does not understand the structure of the filesystem and therefore is incapable of repairing inconsistencies
You will have to be more specific about what you mean. You are correct that it does not repair metadata inconsistencies, but that is because those are handled in a different way. The #1 thing fsck does for an ext filesystem is replay the journal upon a power-failure event. For zfs you don't need a fsck for this because the ZIL is replayed automatically every time the pool is activated. The #2 thing fsck allows you to do is manually repair inconsistencies that can't be restored by the journal. However, this is a mostly useless function as about the only thing you can do is delete orphaned inodes. You can get your filesystem mountable, but there is no way to verify what state the data is actually in afterward (did you just lose data, or did you merge some successful writes with some failed writes effectively corrupting your data?). With zfs, all writes are transactional. So if there is a metadata inconsistency that can't be repaired by replaying the ZIL, you just end up rolling back the whole transaction. You will lose new data, but you won't corrupt existing data.
Can you run into an obscure zfs bug that causes you to unrecoverably lose your entire pool? Yes, of course, which is why you need good backups in every case. But these aren't random inconsistency errors that one might expect to happen in any normal situation. If you were to corrupt the ext4 superblocks you would be just as screwed.
I looked at doing something similar, but FreeNAS now needs 8 GB of RAM.
Meh. I played around with FreeNAS for a while but wasn't too impressed. It makes some things easy. If the preconfigured setup does everything you need, great, but if you need access to more configuration options/customization (like I did), it's a pita. Just grab a copy of zfsonlinux and role your own. It's really not much more complicated than any other filesystem+lvm setup.
Um, what?
zfs scrub
Just because it isn't called fsck doesn't mean it doesn't have one.
Yes, absolutely. However, the nanopore sequencer has to have more than one limited-applicability advantage for it to be commercially successful against competitors. Just consider seriously for a minute what has actually been described (not hyped about) in this paper.
1) A mobile lab in a suitcase including sequencer - yes, that's awesome
2) Deployed to a region experiencing an outbreak
- ok, can be useful, but how many outbreaks occur every year that actually benefit from on-site sequencing
- in the case of Ebola, which spreads and mutates quickly, the advantage may be very real, but Zika? the flu? not so sure
- is the advantage enough to offset the tremendous cost compared to alternatives?
3) They did sequence a segment of the viral genome (not the whole genome) and successfully call base mismatches
- but they didn't call indels
- they ignored homopolymer regions and the ends of their amplicons
- they did get some useful information, but there were samples that they couldn't successfully analyze after sequencing
So in the end, it is a sequencer that can be deployed to remote villages, provided you have a very limited set of analyses you intend to do, and you don't care about the cost. But is that enough to be commercially viable and displace competitors? I don't think so.
I'm not trying to rag on Oxford Nanopore, don't get me wrong. If they really could reliably sequence whole genomes fast and with minimal preparation from a usb stick, I would definitely jump on the bandwagon. I'm just tired of all the hype. They've been promising these breakthroughs for more than a decade now, but they have yet to deliver. Meanwhile other companies, namely PacBio, have appeared and been very successful at providing long reads at an affordable cost, so I'm not holding my breath for ONP.
though if necessary you could presumably do many additional passes to bring the error rate down further.
In its present state, not really. The biggest problem with nanopore data right now is systematic errors in homopolymer regions. These can't be easily corrected out with higher coverage. Incidentally, some of the most significant mutation events are in homopolymer regions, so this is bad.
but it's more than sufficient to recognize a virus.
Correct. But you need to know more. In particular, which strain of virus? Strain variations can easily be much less than 4%.
but so long as you're taking many samples from a community you can probably make a pretty high-confidence conclusion about even SNPs
If the errors were mostly random, you are correct. That is the problem here, the errors are systematic, not random, which is why they can't be corrected out with higher coverage. The good news, though, is that if you are looking at other types of mutations, like inversions or repeat expansions, that are easier to identify than SNPs, the error rate is probably good enough.
Not perfect, but a huge improvement over simply guessing at the path of infection.
You don't have to guess. You just have to use a different sequencing technology. Almost every vendor is trying to provide a rapid sequencing service for this exact reason. Illumina has MiSeq (12-24 hrs. run time), and PacBio is always fast (run time ~3 hrs) as is Ion Torrent (run time ~2 hrs). The biggest advantage that ONP has is portability, but if you need a lab (and an Internet connection) anyway to process samples, I'm not sure that this will really play out to their favor in the long run. ONP gets a lot of awe and excitement, which leads to a lot of hype, but not a lot of practical advantages.
Only if the error is random, which it is not in this case.
Or maybe they're already doing that and accuracy plateaus at 96%
Yes, this is correct.
They're not trying to do genome-research class sequencing, they just need to identify the DNA strands of interest
Well, it does depend on what kind of downstream analysis they plan to do, but 96% is not great. That is 1 error per 25 bases. Good enough for alignment procedures to work, but definitely bad if you are looking for SNPs.
As one commenter on ONP has been stating for a while: what's the point of a portable sequencer if you have to haul around a full-size Illumina sequencer along with it to get the accuracy you need?
The nanopore's advantage in this example is the virus genome, which is a relatively small size, and a well-defined reference sequence. In its present state, the nanopore is mostly useless for larger, previously unsequenced, genomes on a cost/bp basis.
> Base calling accuracy: up to 96%
Um, bullshit. See, this has been the problem with Oxford Nanopore since the beginning. They distract and confuse through a lot of misleading statements and media hype, which is why I can't trust any of their claims. The typical accuracy of single-pass 1D reads on real data is about 70%, about 80% on 2D reads. The 96% accuracy they are quoting on their site is after they error-correct the reads.