> I'm sure they're going to get around to firing as many as they can ASAP.
Did you notice in the summary it said Amazon has 47% MORE employees than they did a year ago, even not counting the aquisitions? They're hiring like crazy. They're working hard and finding more people to hire, running radio ads in my city.
> I also wonder if Amazon is going to find a way to jettison its low-margin retail business and concentrate on AWS.
AWS is only 10% of Amazon's business. A very successful 10%, but only 10%. Amazon didn't buy it's own fleet of delivery trucks this year in order to not use them.
I'm afraid the marketing has tricked you. EU organic regulations are that the pesticides must be of natural (impure) origin rather than being produced synthetically (and more pure). Safer pesticides which aren't readily available from natural sources aren't allowed, so organic farms must use the following more dangerous pesticides.
Here are some pesticides used in organic agriculture, with their median lethal doses:
Copper(II) sulfate is used as a fungicide and is also used in conventional agriculture (LD50 300 mg/kg). Conventional agriculture has the option to use the less toxic Mancozeb (LD50 4,500 to 11,200 mg/kg) Boric acid is used as stomach poison that target insects (LD50: 2660 mg/kg). Pyrethrin comes from chemicals extracted from flowers of the genus Pyrethrum (LD50 of 370 mg/kg). Its potent toxicity is used to control insects. Lime sulphur (aka calcium polysulfide) and sulfur are considered to be allowed, synthetic materials[177] (LD50: 820 mg/kg) Rotenone is a powerful insecticide that was used to control insects (LD50: 132 mg/kg). Despite the high toxicity of Rotenone to aquatic life and some links to Parkinson disease the compound is still allowed in organic farming as it is a naturally occurring compound.[178] Bromomethane is a gas that is still used in the nurseries of Strawberry organic farming[179] Azadirachtin is a wide spectrum very potent insecticide. Almost non toxic to mammals (LD50 in rats is > 3,540 mg/kg) but affects beneficial insects.
>. You sound like an expert in the area. I'd like to hear your explanation for growing pollen allergies, food allergies, food intolerance, etc. Also - are there any long term (i.e. tens of years) studies confirming that there are no ill nor chronic effects? If no, then at best you can claim: "we don't know".
I'd like to hear your evidence for ANY of what you just claimed. If no, then the best you can claim is "is I don't know - what I'm talking about"
> ZFS has checksums to figure out which is right. MDADM doesn't.
You have no idea how RAID works, do you? Neither through the mdadm UI or any other.
RAID level 2 uses Hamming error correction codes. Levels 3 through 5 use checksums much like ZFS does. Level 6 uses two independent sets of checksums, so even if you lose half your checksums, you're still okay.
>. if there is an API to allow you to ask for data from a specific disk rather than letting the RAID driver pick one, I'm interested.
An API to read from sda? Uhm, it's called read(). You very simply read from sda or whichever drive rather than reading from md0. That's how you can boot from a RAID 1 partition without the BIOS or bootloader knowing anything about RAID - it just reads from any of the member disks.
> Until mdadm and hardware RAID controllers allow you to issue a "read, but try to give a different result" operation you can't do this. (Said operation would attempt to use parity even on a healthy array in an attempt to give a different block content by pretending a disk is dead).
So until the late 1980s? That's called RAID scrubbing and I believe it was mentioned toward the end of the original RAID paper in 1987 or 1988. Certainly 10 years ago I had a "mdadm check" command in my crontab. I know this for sure because I still have a copy of my 2007 server image.
The "mdadm repair" command was also in use by then. Cool "new feature" you've got there.
I'll respond to your other two gross misunderstandings about raid by replying to your other post.
> The problem with ZFS on Linux is that some aspects of it are redundant with the kernel.
Probably ALL aspects of it. Linux already has a raid implementation in-kernel. It already has filesystems. It already has multiple volume managers, which handle whichever type of snapshots you prefer. It already has IO schedulers. ZFS, or rather something that looks just like it, can be implemented as a few configuration lines for pre-existing Linux components.
Because Linux normally lets you use your choice of file system on top of your choice of volume manager, on top of whichever RAID implementation you choose, with your choice of IO scheduling options, ZFS isn't exactly the best fit. ZFS mashes all those different things into one big blob. That's not really how Linux is designed.
That's the same issue as systemd - it may (or may not) be a good init system. It may or may not be a good logging system. It may possibly be a good DNS server (probably not). But it can't seem to decide wtf it is.
> How is the copyright of those? I'm talking about things which were cool back in the 1980s -- not only games, but serious applications, too.
Unfortunately the bills to address this in US law haven't passed. It doesn't seem like there is a ton of opposition, there just isn't enough interest to push a bill all the way through both houses of Congress. (Bills have passed one house or the other at different times.)
Some of them are open source or public domain. If you to to distribute any proprietary ones, try to contact the author before SELLING them. If it was made by a company that has since gone out of business, you're probably safe giving copies away. It's technically not legal to give them away, but a law suit from an author who appears wouldn't be able to claim much in the way of damages.
Copyright infringement and fair use gets a little complicated, but it's all centered around the idea that you can't sell someone else's work IN COMPETITION with their own authorized sales. If you're a) not selling and b) not giving copies to people who might have otherwise bought a copy from the author, you probably won't get in much trouble zero even though it's not actually legal.
>. There really isn't a good way to use them, the exception being the EMP pulsing
And of course the way we've BEEN using them, as deterrents. I'd say the primary use of nukes is with them remaining in their silos. Having them in strategic locations has been very useful, without pressing the button.
Here we have the US military using them, by freshening up the paint on the runway near them. That gets people's attention, and that's the point.
"Replaces" does not mean "derived from". Cars replace horses. Cars are not derived from horses. More to the point, GPL Linux replaces Unix; Linux is not a derivative work of Unix.
SCO spent millions on lawyers arguing that Linux is a derivative work of Unix, which it replaces. Several courts ruled it is not. It's entirely possible to replace something without creating a derivative work.
> Anyone who has worked on the part to be eliminated need not apply
Partially true. Someone who really knows the old code inside and out would need to write a significantly better or different replacement, in order to make I clear that it's not essentially the same implementation. Someone very familiar with it may know of fundamental problems with the old approach and have ideas about a new, better approach. That would be fine. If an existing developer doesn't have ideas for a new approach, it's best that the new code be written by someone unfamiliar with the implementation details of the old code.
Even in enforcing a license, a court must decide how exactly to do so. If monetary damages are appropriate, how much money exactly? A court should hear from the copyright holders and from the defendant before deciding on remedies.
As you said, there are many contributors to the kernel, and many contributors to netfilter. If the vast majority of copyright holders relevant copy right holders say "we just want them to start complying, we don't want any money other than expenses for this case", a court should duly noted that.
Where one person has contributed much less than 1% of the code
True, payment can also be used to encourage compliance BEFORE getting caught. "If you don't comply from the start, you'll have to pay when you get caught", is one approach. It seem McHardy is seeking personal gain, though, based on his tactics of putting time pressure on them, etc.
There may be no right way to do it. Giving a warning and allowing them to come into compliance with no penalty makes sense if someone just goofed. On the other hand, a policy of always allowing 30 days to cure with penalty could be interpreted as "there's no reason to comply until after you get caught". The best approach, IMHO, may be a small penalty for non-compliance as soon as someone gets caught - enough penalty that it makes sense for companies to comply BEFORE they get caught, and 30 days to fix it before more significant penalties are pursued.
I'm about to start working on my masters degree from Harvard, after finishing my bachelor's at WGU. You know why I'm doing my masters at Harvard instead of staying at WGU? Because a Harvard degree is more likely to get me offers at a higher salary. Why? Because Harvard grads have a reputation for knowing their shit.
Of course Harvard charges students more than WGU or UNT. They need to in order to pay top-tier faculty and they can because of their reputation - Harvard's reputation for excellent education brings them money.
> Was there any financial harm? Or it's just someone's reputation
Reputational harm IS financial harm in this case. The value of a degree, the amount of money employers and therefore students will pay for a degree from that school is directly related to the school's reputation. If the school gives out degrees to people who don't have a clue, but cheated to get a good grade, degrees from that school eventually become worthless. If they don't strongly enforce an academic honestly policy, that causes financial harm to everyone who went to school there, because their degrees would no longer represent knowledge.
> you basically cannot trust ANYTHING outsourced these days, and must constantly monitor it for quality. Which begs the question, why outsource then if you must also incur the added cost of verification and riding herd on QA
Your good options are:
1) Buy from a steel company and test a statistically appropriate number of samples 2) Build and operate your own foundry and test a statistically appropriate number of samples
You need to test either way. The question is, "which is better, buying steel from a company that is good at making steel, or build and operate your own steel company?" If you're in the business of making appliances, or bottle caps, or lawn sprinklers, or anything other than refining steel, buying from an existing steel maker is probably a better idea than launching your own foundry.
Of course there are also two wrong ways to do it:
1) Buy from a steel company and never test any of it 2) Build and operate your own foundry and never test any of it
Either of those will end up with you using sub-standard steel.
Our company does basically that, with laptops. Most people work from home most of the time, but I can go into any of the company's office buildings and find a seat. Of course I have to use my badge to get into the building.
Most people have a "home" office or cube they *normally* use, but you're not restricted to only using that one. If you feel like sitting by the window today, do so. I use "my" office once a week, working from home 4 days a week. When I'm not there (most of the time), someone visiting from Europe or wherever can use it.
>. It is a shame that we live in times where people on the far right and hate groups are becoming emboldened because of the poor example our country's leadership is setting. I hate bringing politics into this, but leadership that encourages hatred emboldens
So it's Obama's fault this happened? (In case you didn't know, he was president in 2015, when this happened.). Good thing we now have new leadership so people who were discriminated against under Obama can now safely bring their plight out in the open, huh?
You might be right. The Dems DO spend a ridiculous amount of time talking about race, making everything racial, trying to keep people constantly separating themselves based on the color of their skin, as if their complexion were the most important thing in the world. Of course when the county's leaders are constantly trying to divide people based on racial groups, you'll have some people buy into their identity politics, their racial stereotyping, and that'll lead to an us-vs-them mentality sometimes.
The "REGULATIONS" I had to follow on government-sponsored projects *required* we use outdated, thoroughly broken suckerity, such as MD5. It takes less than one second to break MD5. We're not allowed to use effective algorithms such as SHA256, we must use the completely broken MD5. These regulations were of course promulgated by the Obama administration.
I would LOVE it if information security could be fixed by regulation. I'd love it even more if it could be fixed by whining about the other team. Sadly, this is real life, not sports, so rooting for your favorite team does nothing.
> I specify that Congress should make broad legislation allowing a regulatory agency to select the most-appropriate, affordable, and effective technology of today;
They did. The federal government requires MD5. SHA256 is not acceptable for many federal uses (though it is now FIPS), because they haven't updated the relevant federal standards. Our system of government was designed to be fair, transparent, and flexible. It was not designed to be fast and efficient.
That's what I was thinking, but I wouldn't mind having all the pics on my phone automatically organized by face recognition. Anybody know the best way to do this on Linux, locally? Obviously it wouldn't know WHO they are, just recognize "these two pics are the same person". 10 or 15 years ago I used some popular Linux program that did a pretty good job of putting similar pics together, but I'm sure today's options are much better.
I pretty much told you how to do it, and marked that with "(this is a big hint)". Do you want to solve your problem, do you want to know how we do it, or do you want to keep arguing that it can't be done?
According to the article, it affected fewer than 1% of customers that weekend, the intrusion was stopped within 28 hours, and they've called in outside experts to take an objective look at it and help them improve their security posture. They did get hacked, AND they are doing some things right.
It looks like they had some monitoring in place that caught it - good. They are getting assistance from security professionals - good. Those professionals don't work for the same internal IT department that had a deficiency in the first place - good.
The fact that they got hacked means there were several things wrong. They should have had multiple layers of security. Yet they are also doing some things right.
> I'm afraid that rsync normally deletes the local file and replaces it with the new file
---inplace
>. "bind mounts" do not work for individual files in Linux filesystems
That's what I said. I said "if you're symlinking to a directory, consider bind mounts"
> and does not happen if the hardlink leads outside the target rsync directory.
Hard links don't lead to any directory. Hard links (aka file names) lead to disk blocks. We call them "hard links" when two or more different file names happen to lead to the same disk blocks, but neither name refers to any other. They are just regular file names, pointing to blocks on disk.
> Rsycing hardlinks is quite tricky Which is why we provide options such as: --copy-dest --link-dest --backup ---inplace
You're also allowed to run rsync twice, with different options, in a two-step process (that's a big giant hint right there)
> less experienced systems personnel believe that their casual familiarity with a tool applies to edge cases. It's when they have to actually do the work and deal with edge cases that they learn
People who didn't even read the man page carefully believe that their casual familiarity with the tool applies to edge cases. It's when they actually do the code in rsync, writing options that handle edge cases, that they learn how it actually works.
> I do apologize if I seem condescending about this: My experience with rsync and its limitations is hard-won, and its subtleties can be confusing.
I do apologize if I seem condescending about this: My experience with rsync is from stepping through the code and contributing improvements; the subtleties of my code can be confusing. (Especially if you don't read the entire man page)
When the only tool you have is a hammer, everything looks like a nail.
What would you think of a handyman whose answer to everything is "use a ball-peen hammer"? You might notice that's the only tool he has, a ball peen hammer. No screwdriver, no wrench, just a ball peen hammer.
Rust is like a ball peen hammer. There are a few jobs for which Rust is the right tool. For 98% of programming needs, another common tool is clearly a better fit. The limited memory safety Rust fanbois are so proud of is also true of EVERY interpreted language going back to the 1950s.
You newbie fanbois sound like if a Ford afficiando went on and on about "Ford trucks have FOUR cup holders!". The advantage you're so proud of is neither particularly uncommon or all THAT damn important.
In fact, it makes YOUR code less safe because you think that because the language eliminates ONE small class of errors (the same errors every interpreted language also protects against), that means you're safe and don't have to be careful. That's like if you have a great lock on your glovebox, so you leave your damn car unlocked while screaming "nobody can steal stuff from MY glovebox". Well, you're missing most of the risks while ranting about protection from one small category of risk.
So the source is NOT a symlink. You want the destination to be a symlink, and you want it to copy from src/a/file to destination/b/somewhere/ file ? So the file contents up up somewhere totally different than where they are on the source, based on a previously existing symlink on the destination?
If I'm understanding you correctly, you can probably achieve the same goal by trading the symlink for either a hard link or a bind mount. If the symlink points to a directory, use a bind mount instead. If the symlink points to a plain file, consider a hard link.
Originally, the protocol was designed to be able to have fixtures talk back to the controller, without a request from the controller first. That's why the standard specifies a five-pin connector - one pair for data from the controller, one pair for data back from fixtures, and a ground. The exact protocol for fixture-to-controller communication wasn't established, but the standard said there should be a pair of wires for that, so that a later version could define the specifics.
Unfortunately people didn't follow the protocol specification. American manufacturers use a three-pin connectors, the same connectors as audio cables. European manufacturers used the other pair of wires for all sorts of different things.
The other reason the protocol required a five-pin connector was to avoid exactly what the American manufacturers did - having the DMX connector match the audio connector. That makes it very easy, when quickly running dozens of cables before a show, to accidentally connect an audio device to the lighting network or vice-versa. When a DMX fixture is attached to a mic cable with 48V phantom power for the mic, it can destroy the fixture. The DMX chip is designed to accept up to 12 volts, not the 48 volts that some microphones take. Conversely, accidentally connecting a lighting console to a passive microphone can ruin the mic. Mics are designed to output millivolts at 2Khz sine wave, they aren't designed to be fed 12V at 250Khz square wave. If manufacturers followed the standard, it wouldn't be possible to connect DMX and microphones together, because they are supposed to have different connectors.
Similarly, using microphone cable rather than DMX cable is a common cause of unreliable DMX control. Mic cables are designed to Max out at 2Khz and can have significant capacitance. DMX operates at 250Khz and needs cables with acceptably low capacitance.
Ignore the following.
The Slashdot lameness filter is tripping on this post because it I used the same words multiple times. Based on gzip, it looks for repetition. Repeated characters, words, or phrases compress well and could indicate a silly post such as ascii arts with lots of spaces. To get around this stupidness I have to add random words to the post which will reduce how well it compresses.
Slashdot Mirror
> I'm sure they're going to get around to firing as many as they can ASAP.
Did you notice in the summary it said Amazon has 47% MORE employees than they did a year ago, even not counting the aquisitions? They're hiring like crazy. They're working hard and finding more people to hire, running radio ads in my city.
> I also wonder if Amazon is going to find a way to jettison its low-margin retail business and concentrate on AWS.
AWS is only 10% of Amazon's business. A very successful 10%, but only 10%. Amazon didn't buy it's own fleet of delivery trucks this year in order to not use them.
I'm afraid the marketing has tricked you.
EU organic regulations are that the pesticides must be of natural (impure) origin rather than being produced synthetically (and more pure). Safer pesticides which aren't readily available from natural sources aren't allowed, so organic farms must use the following more dangerous pesticides.
Here are some pesticides used in organic agriculture, with their median lethal doses:
Copper(II) sulfate is used as a fungicide and is also used in conventional agriculture (LD50 300 mg/kg). Conventional agriculture has the option to use the less toxic Mancozeb (LD50 4,500 to 11,200 mg/kg)
Boric acid is used as stomach poison that target insects (LD50: 2660 mg/kg).
Pyrethrin comes from chemicals extracted from flowers of the genus Pyrethrum (LD50 of 370 mg/kg). Its potent toxicity is used to control insects.
Lime sulphur (aka calcium polysulfide) and sulfur are considered to be allowed, synthetic materials[177] (LD50: 820 mg/kg)
Rotenone is a powerful insecticide that was used to control insects (LD50: 132 mg/kg). Despite the high toxicity of Rotenone to aquatic life and some links to Parkinson disease the compound is still allowed in organic farming as it is a naturally occurring compound.[178]
Bromomethane is a gas that is still used in the nurseries of Strawberry organic farming[179]
Azadirachtin is a wide spectrum very potent insecticide. Almost non toxic to mammals (LD50 in rats is > 3,540 mg/kg) but affects beneficial insects.
>. You sound like an expert in the area. I'd like to hear your explanation for growing pollen allergies, food allergies, food intolerance, etc. Also - are there any long term (i.e. tens of years) studies confirming that there are no ill nor chronic effects? If no, then at best you can claim: "we don't know".
I'd like to hear your evidence for ANY of what you just claimed. If no, then the best you can claim is "is I don't know - what I'm talking about"
> ZFS has checksums to figure out which is right. MDADM doesn't.
You have no idea how RAID works, do you? Neither through the mdadm UI or any other.
RAID level 2 uses Hamming error correction codes.
Levels 3 through 5 use checksums much like ZFS does. Level 6 uses two independent sets of checksums, so even if you lose half your checksums, you're still okay.
>. if there is an API to allow you to ask for data from a specific disk rather than letting the RAID driver pick one, I'm interested.
An API to read from sda? Uhm, it's called read(). You very simply read from sda or whichever drive rather than reading from md0. That's how you can boot from a RAID 1 partition without the BIOS or bootloader knowing anything about RAID - it just reads from any of the member disks.
> Until mdadm and hardware RAID controllers allow you to issue a "read, but try to give a different result" operation you can't do this. (Said operation would attempt to use parity even on a healthy array in an attempt to give a different block content by pretending a disk is dead).
So until the late 1980s? That's called RAID scrubbing and I believe it was mentioned toward the end of the original RAID paper in 1987 or 1988. Certainly 10 years ago I had a "mdadm check" command in my crontab. I know this for sure because I still have a copy of my 2007 server image.
The "mdadm repair" command was also in use by then.
Cool "new feature" you've got there.
I'll respond to your other two gross misunderstandings about raid by replying to your other post.
> The problem with ZFS on Linux is that some aspects of it are redundant with the kernel.
Probably ALL aspects of it. Linux already has a raid implementation in-kernel. It already has filesystems. It already has multiple volume managers, which handle whichever type of snapshots you prefer. It already has IO schedulers. ZFS, or rather something that looks just like it, can be implemented as a few configuration lines for pre-existing Linux components.
Because Linux normally lets you use your choice of file system on top of your choice of volume manager, on top of whichever RAID implementation you choose, with your choice of IO scheduling options, ZFS isn't exactly the best fit. ZFS mashes all those different things into one big blob. That's not really how Linux is designed.
That's the same issue as systemd - it may (or may not) be a good init system. It may or may not be a good logging system. It may possibly be a good DNS server (probably not). But it can't seem to decide wtf it is.
> How is the copyright of those? I'm talking about things which were cool back in the 1980s -- not only games, but serious applications, too.
Unfortunately the bills to address this in US law haven't passed. It doesn't seem like there is a ton of opposition, there just isn't enough interest to push a bill all the way through both houses of Congress. (Bills have passed one house or the other at different times.)
Some of them are open source or public domain. If you to to distribute any proprietary ones, try to contact the author before SELLING them. If it was made by a company that has since gone out of business, you're probably safe giving copies away. It's technically not legal to give them away, but a law suit from an author who appears wouldn't be able to claim much in the way of damages.
Copyright infringement and fair use gets a little complicated, but it's all centered around the idea that you can't sell someone else's work IN COMPETITION with their own authorized sales. If you're a) not selling and b) not giving copies to people who might have otherwise bought a copy from the author, you probably won't get in much trouble zero even though it's not actually legal.
>. There really isn't a good way to use them, the exception being the EMP pulsing
And of course the way we've BEEN using them, as deterrents. I'd say the primary use of nukes is with them remaining in their silos. Having them in strategic locations has been very useful, without pressing the button.
Here we have the US military using them, by freshening up the paint on the runway near them. That gets people's attention, and that's the point.
"Replaces" does not mean "derived from". Cars replace horses. Cars are not derived from horses. More to the point, GPL Linux replaces Unix; Linux is not a derivative work of Unix.
SCO spent millions on lawyers arguing that Linux is a derivative work of Unix, which it replaces. Several courts ruled it is not. It's entirely possible to replace something without creating a derivative work.
> Anyone who has worked on the part to be eliminated need not apply
Partially true. Someone who really knows the old code inside and out would need to write a significantly better or different replacement, in order to make I clear that it's not essentially the same implementation. Someone very familiar with it may know of fundamental problems with the old approach and have ideas about a new, better approach. That would be fine. If an existing developer doesn't have ideas for a new approach, it's best that the new code be written by someone unfamiliar with the implementation details of the old code.
Even in enforcing a license, a court must decide how exactly to do so. If monetary damages are appropriate, how much money exactly? A court should hear from the copyright holders and from the defendant before deciding on remedies.
As you said, there are many contributors to the kernel, and many contributors to netfilter. If the vast majority of copyright holders relevant copy right holders say "we just want them to start complying, we don't want any money other than expenses for this case", a court should duly noted that.
Where one person has contributed much less than 1% of the code
True, payment can also be used to encourage compliance BEFORE getting caught. "If you don't comply from the start, you'll have to pay when you get caught", is one approach. It seem McHardy is seeking personal gain, though, based on his tactics of putting time pressure on them, etc.
There may be no right way to do it. Giving a warning and allowing them to come into compliance with no penalty makes sense if someone just goofed. On the other hand, a policy of always allowing 30 days to cure with penalty could be interpreted as "there's no reason to comply until after you get caught". The best approach, IMHO, may be a small penalty for non-compliance as soon as someone gets caught - enough penalty that it makes sense for companies to comply BEFORE they get caught, and 30 days to fix it before more significant penalties are pursued.
I'm about to start working on my masters degree from Harvard, after finishing my bachelor's at WGU. You know why I'm doing my masters at Harvard instead of staying at WGU? Because a Harvard degree is more likely to get me offers at a higher salary. Why? Because Harvard grads have a reputation for knowing their shit.
Of course Harvard charges students more than WGU or UNT. They need to in order to pay top-tier faculty and they can because of their reputation - Harvard's reputation for excellent education brings them money.
> Was there any financial harm? Or it's just someone's reputation
Reputational harm IS financial harm in this case. The value of a degree, the amount of money employers and therefore students will pay for a degree from that school is directly related to the school's reputation. If the school gives out degrees to people who don't have a clue, but cheated to get a good grade, degrees from that school eventually become worthless. If they don't strongly enforce an academic honestly policy, that causes financial harm to everyone who went to school there, because their degrees would no longer represent knowledge.
> you basically cannot trust ANYTHING outsourced these days, and must constantly monitor it for quality. Which begs the question, why outsource then if you must also incur the added cost of verification and riding herd on QA
Your good options are:
1) Buy from a steel company and test a statistically appropriate number of samples
2) Build and operate your own foundry and test a statistically appropriate number of samples
You need to test either way. The question is, "which is better, buying steel from a company that is good at making steel, or build and operate your own steel company?" If you're in the business of making appliances, or bottle caps, or lawn sprinklers, or anything other than refining steel, buying from an existing steel maker is probably a better idea than launching your own foundry.
Of course there are also two wrong ways to do it:
1) Buy from a steel company and never test any of it
2) Build and operate your own foundry and never test any of it
Either of those will end up with you using sub-standard steel.
Our company does basically that, with laptops. Most people work from home most of the time, but I can go into any of the company's office buildings and find a seat. Of course I have to use my badge to get into the building.
Most people have a "home" office or cube they *normally* use, but you're not restricted to only using that one. If you feel like sitting by the window today, do so. I use "my" office once a week, working from home 4 days a week. When I'm not there (most of the time), someone visiting from Europe or wherever can use it.
It works pretty well for us.
>. It is a shame that we live in times where people on the far right and hate groups are becoming emboldened because of the poor example our country's leadership is setting. I hate bringing politics into this, but leadership that encourages hatred emboldens
So it's Obama's fault this happened? (In case you didn't know, he was president in 2015, when this happened.). Good thing we now have new leadership so people who were discriminated against under Obama can now safely bring their plight out in the open, huh?
You might be right. The Dems DO spend a ridiculous amount of time talking about race, making everything racial, trying to keep people constantly separating themselves based on the color of their skin, as if their complexion were the most important thing in the world. Of course when the county's leaders are constantly trying to divide people based on racial groups, you'll have some people buy into their identity politics, their racial stereotyping, and that'll lead to an us-vs-them mentality sometimes.
The "REGULATIONS" I had to follow on government-sponsored projects *required* we use outdated, thoroughly broken suckerity, such as MD5. It takes less than one second to break MD5. We're not allowed to use effective algorithms such as SHA256, we must use the completely broken MD5. These regulations were of course promulgated by the Obama administration.
I would LOVE it if information security could be fixed by regulation. I'd love it even more if it could be fixed by whining about the other team. Sadly, this is real life, not sports, so rooting for your favorite team does nothing.
> I specify that Congress should make broad legislation allowing a regulatory agency to select the most-appropriate, affordable, and effective technology of today;
They did. The federal government requires MD5. SHA256 is not acceptable for many federal uses (though it is now FIPS), because they haven't updated the relevant federal standards. Our system of government was designed to be fair, transparent, and flexible. It was not designed to be fast and efficient.
I couldn't remember the name of it, but I think it was digiKam I used many years ago. I bet it's really good now.
>. not uploading my goddamn photos to google (
That's what I was thinking, but I wouldn't mind having all the pics on my phone automatically organized by face recognition. Anybody know the best way to do this on Linux, locally? Obviously it wouldn't know WHO they are, just recognize "these two pics are the same person". 10 or 15 years ago I used some popular Linux program that did a pretty good job of putting similar pics together, but I'm sure today's options are much better.
I pretty much told you how to do it, and marked that with "(this is a big hint)". Do you want to solve your problem, do you want to know how we do it, or do you want to keep arguing that it can't be done?
According to the article, it affected fewer than 1% of customers that weekend, the intrusion was stopped within 28 hours, and they've called in outside experts to take an objective look at it and help them improve their security posture. They did get hacked, AND they are doing some things right.
It looks like they had some monitoring in place that caught it - good.
They are getting assistance from security professionals - good.
Those professionals don't work for the same internal IT department that had a deficiency in the first place - good.
The fact that they got hacked means there were several things wrong. They should have had multiple layers of security. Yet they are also doing some things right.
> I'm afraid that rsync normally deletes the local file and replaces it with the new file
---inplace
>. "bind mounts" do not work for individual files in Linux filesystems
That's what I said. I said "if you're symlinking to a directory, consider bind mounts"
> and does not happen if the hardlink leads outside the target rsync directory.
Hard links don't lead to any directory. Hard links (aka file names) lead to disk blocks. We call them "hard links" when two or more different file names happen to lead to the same disk blocks, but neither name refers to any other. They are just regular file names, pointing to blocks on disk.
> Rsycing hardlinks is quite tricky
Which is why we provide options such as:
--copy-dest
--link-dest
--backup
---inplace
You're also allowed to run rsync twice, with different options, in a two-step process (that's a big giant hint right there)
> less experienced systems personnel believe that their casual familiarity with a tool applies to edge cases. It's when they have to actually do the work and deal with edge cases that they learn
People who didn't even read the man page carefully believe that their casual familiarity with the tool applies to edge cases. It's when they actually do the code in rsync, writing options that handle edge cases, that they learn how it actually works.
> I do apologize if I seem condescending about this: My experience with rsync and its limitations is hard-won, and its subtleties can be confusing.
I do apologize if I seem condescending about this: My experience with rsync is from stepping through the code and contributing improvements; the subtleties of my code can be confusing. (Especially if you don't read the entire man page)
When the only tool you have is a hammer, everything looks like a nail.
What would you think of a handyman whose answer to everything is "use a ball-peen hammer"? You might notice that's the only tool he has, a ball peen hammer. No screwdriver, no wrench, just a ball peen hammer.
Rust is like a ball peen hammer. There are a few jobs for which Rust is the right tool. For 98% of programming needs, another common tool is clearly a better fit. The limited memory safety Rust fanbois are so proud of is also true of EVERY interpreted language going back to the 1950s.
You newbie fanbois sound like if a Ford afficiando went on and on about "Ford trucks have FOUR cup holders!". The advantage you're so proud of is neither particularly uncommon or all THAT damn important.
In fact, it makes YOUR code less safe because you think that because the language eliminates ONE small class of errors (the same errors every interpreted language also protects against), that means you're safe and don't have to be careful. That's like if you have a great lock on your glovebox, so you leave your damn car unlocked while screaming "nobody can steal stuff from MY glovebox". Well, you're missing most of the risks while ranting about protection from one small category of risk.
So the source is NOT a symlink. You want the destination to be a symlink, and you want it to copy from src/a/file to destination/b/somewhere/ file ? So the file contents up up somewhere totally different than where they are on the source, based on a previously existing symlink on the destination?
If I'm understanding you correctly, you can probably achieve the same goal by trading the symlink for either a hard link or a bind mount. If the symlink points to a directory, use a bind mount instead. If the symlink points to a plain file, consider a hard link.
Originally, the protocol was designed to be able to have fixtures talk back to the controller, without a request from the controller first. That's why the standard specifies a five-pin connector - one pair for data from the controller, one pair for data back from fixtures, and a ground. The exact protocol for fixture-to-controller communication wasn't established, but the standard said there should be a pair of wires for that, so that a later version could define the specifics.
Unfortunately people didn't follow the protocol specification. American manufacturers use a three-pin connectors, the same connectors as audio cables. European manufacturers used the other pair of wires for all sorts of different things.
The other reason the protocol required a five-pin connector was to avoid exactly what the American manufacturers did - having the DMX connector match the audio connector. That makes it very easy, when quickly running dozens of cables before a show, to accidentally connect an audio device to the lighting network or vice-versa. When a DMX fixture is attached to a mic cable with 48V phantom power for the mic, it can destroy the fixture. The DMX chip is designed to accept up to 12 volts, not the 48 volts that some microphones take. Conversely, accidentally connecting a lighting console to a passive microphone can ruin the mic. Mics are designed to output millivolts at 2Khz sine wave, they aren't designed to be fed 12V at 250Khz square wave. If manufacturers followed the standard, it wouldn't be possible to connect DMX and microphones together, because they are supposed to have different connectors.
Similarly, using microphone cable rather than DMX cable is a common cause of unreliable DMX control. Mic cables are designed to Max out at 2Khz and can have significant capacitance. DMX operates at 250Khz and needs cables with acceptably low capacitance.
Ignore the following. The Slashdot lameness filter is tripping on this post because it I used the same words multiple times. Based on gzip, it looks for repetition. Repeated characters, words, or phrases compress well and could indicate a silly post such as ascii arts with lots of spaces. To get around this stupidness I have to add random words to the post which will reduce how well it compresses.