A feeling can also add something. So if I make a comment and include a feeling that adds a sort of 'wink wink, nudge nudge say no more' to a normal statement, that can be offensive.
Also, 'emoticon' started as ways to add facial expressions, and as they progressed to 'emoji' it became about ideograms as well, to state things that are concrete absent of emotion.
For example, If someone was trying to plan a lunch, and asked me what I thought a coworkers favorite food was, and I replied with an Eggplant emoji, then that could be harassment and/or defamatory.
In the cited example, it was the emotion that made it *not* defamation. If taken as serious, it might have been defamatory, but the emoji declaring it as a joke was how it was made *not* defamatory.
IPSec doesn't add anything if the peer is the thing to be compromised. That's pretty much the challenge. If things *do* get into your precious internal network, it's malware running on legitimately authenticated systems.
Physical attacks against ethernet ports are nothing compared to how often remote exploits occur.
For security to actually *work*, this is the key thing that must change.
Security in this industry has been about security teams covering their asses, it's not *their* fault if all their efforts to make things secure are bypassed by people trying to get their job done. Security *needs* to be more about understanding the human consequences of the approach being taken.
Yes, this is the whole "shadow IT" thing. Official IT falls short, people wanting to get work done will start supporting each other in creative ways. *Those* well-meaning efforts end up causing the network to be more at risk than if the IT department were more "risky" and actually helped work get done.
So my work set up OTP authentication to get in remotely.
First time around, hadware tokens. Problem: people kept losing them.
Eventually, migrate to OTP for phone use. Problem, people would forget their phones.
Ultimate solution, a website to generate the token that's publicly accessible, that just accepts the same single username/password that they were trying to get away from in the first place.
Anyone in the industry knows *exactly* what'll happen when you inconvenience people with onerous security, they bypass it. Have no viable way to exchange large files? Those files *will* end up publicly shared on google drive. Refuse to set up an internet facing service for some department in a timely fashion? Someone in that department will buy an AWS instance and just do it themself, even if they use a few dollars of their personal money.
Security is about more than locking down access to stuff, it's about facilitating work to be done securely, but within reason. Sometimes that means doing something that isn't perhaps *as* locked down as you would like, but it is better than the alternative.
However, security must also acknowledge reality. The reality is that so long as you empower your employees to do, well, much of anything, they will become potential vectors of an attack. Lock them down to be harmless, they will often also be unable to be productive.
It is worth noting that many of these attacks that happen still do happen because someone dangled part of the information outside the defenses. An improperly set up cloud storage or service has become a frequent source of compromise. These attacks would be rarer in the 'castle and moat' because they happened inside a more protected network. Sure, they shouldn't have been configured that way even internally, but reality is *someone* is going to do something like this, and better for it to be mitigated than in the open.
So the lesson is sure, be as vigiliant as you already *should* have been, but also that going out of the moat is part of the problem, not that the moat is losing efficacy compared to before.
The problem is it is out of gnome shell's hands in wayland. in X they have a responsibility, but that responsibility isn't core to the applications working.
In Wayland architecture, gnome shell is basically the X server. Now they could do a better job segregating their code and have a more bulletproof core to be the wayland compositor, but it's just a whole new role they had never had to handle in the past.
Actually, for executing a remote application, Wayland can accomodate with Xwayland.
Here the thing is sharing your screen, like in a teleconference situation or accessing your whole screen remotely rather than X forwarding which Wayland can't accommodate, in part due to intentional design decisions to mitigate security risks.
Well, it's a bit more than that. The statement has been in various circles 'wayland is good enough *today*, you don't need xorg anymore'
This is acceptance that people do have things they can't do in Wayland, and it needs to be opt-in rather than opt-opt to avoid bad user experience.
It's not 'wayland will *never* be better', but it is a statement that it has a ways to go, and some of the limitations are design choices that will require interesting conversations, particularly about security with regards to screen sharing.
It bears a much closer resemblance to texture processing in 3d modeling apps.There may be other specific domains that have this sort of approach, but web development is certainly not one of them.
Glad to see someone highlighting that beyond brand, additionally product lines matter greatly. All of those vendors also produce exceptionally crappy laptops for low price point, so you have to stick to the 'professional' lines to have a product they are not half-assing.
One, the other big notable accident was also with a vehicle with high ground clearance. At the time it was suggested that the system sensors were basically counting on something relatively close to the ground, and would miss things as they approach 'decaptiation level'.
I will say I am highly skeptical that the car slammed in at full 65 mph into a stopped fire truck. I got rear ended while I was going about 15 mph (traffic jam) by a car that was going about 60, and there were injuries and both cars were in much worse shape than the Tesla pictured (both cars totaled, frames bent so bad that no doors able to open without prybars), and that's with both cars having crumple zones, whereas the fire truck didn't yield much at all and the Tesla had to take the vast majority of the energy of the impact. Also, the Model S is a pretty heavy car, so there had to be a lot of energy in that collision.
One amendment I'd make is for worker's comp. I'll agree one should not be *dependent* upon the employer, but on the other hand there does need to be an ever present knob to twist to have companies self-interest align with worker safety (hazardous environment in theory should translate to higher worker's comp premiums).
The health insurance linked to employer is just bonkers.
The reality is that if they *did* continue the macbook air, it'd follow the same design decisions that the Macbook and Macbook pro did.
The raison d'etre for the macbook air was to have a really skinny laptop, even if it meant compromising on functionality compared to the Macbook when it was released.
Now, they've made all their lines skinny and decided not to bother doing any 'non-air' designs for more power, so air is redundant.
Since Apple is clearly not caring about your opinion anymore, maybe it's time to return the favor and shop elsewhere?
Problem is that if you are doing commercial software as a newcomer, you'll *also* want to go subscription. Subscription is more viable and it means that you have increased likelihood of future revenue even if you sit on your ass and do nothing.
It's consumer-hostile, but those that engage in it are going to out-resource those that do the right thing by the customer in the long run. In some circles, the community doing open source can overturn it, but I wouldn't expect professional competition to provide the answer.
Adobe has a stranglehold on that market, and they can pretty much do whatever they want. They realized that people weren't bothering to buy new versions, and as such their revenue was threatened, so they changed course to a subscription, to guarantee future revenue, unless a competitor came in. No competitors in sight and given the state of software today, it is highly unlikely that another vendor would choose a non-subscription path. I get everything I want out of GIMP personally, so I'm not too personally invested in that per se, but it does serve as an inspiration to all sorts of software vendors as a 'I can't make customers pay for new function, and I can't branch into new markets competently, so I can make them rent the same old software to get revenue and as a bonus, I don't have to work as hard to innovate'.
Hyperbole aside, this isn't new to 'DevOps', though I will admit that in some circles it blesses the thought process.
For as long as humans have been doing things, processes in bad groups devolve to this sort of blind and mad grasping at 'productivity', and devolving into spending more time fretting about the process of seeing if work is being done than actually doing the work. Each fad promising to 'correct' the ratio of overhead of the previous fad, either never realizing or intentionally ignoring the reality that people are the problem and will pervert any methodology that purports to fix it.
Meanwhile, good teams operating within good larger organizations will succeed with whatever project management/development fad they nominally use.
less than a quarter of respondents strongly agree that senior management understands the importance of not sacrificing security for time-to-market success.
So the problem is that senior management may understand, and the answer is not one that security experts like. Financially speaking, it may make sense to be a little fast and loose with security, or at least faster and looser than hardline security guys want. Security problems represent a liability, and for some cases not much liability, some times it *could* ruin your company, depending on what sort of company you are, the data you have, and which part of the data could be hypothetically compromised by the subsystem at hand. These have to be weighed against the cost of prevention both in terms of staffing/consulting and opportunity cost when your paranoia causes you to not implement a scary feature that your competitor does, or to be a year later than a competitor.
Complicating things, there's a disconnect between paranoid security practices and where the largest breaches come from. The vast majority of breaches come from someone putting a crappy credential on something. This is overwhelmingly bad practice and overwhelmingly basic. The reaction to a breach in the industry is for security guys to use it to go to town, enforcing more and more draconian limitations using more and more inscrutable approaches to mitigate risk, even though the existing processes would have already defended them adequately if applied correctly. It's like never taking a shower because you keep reading about people drowning in the ocean. There's not the risk in your shower, but water-related death is a thing, so why take a chance.
Meanwhile, time to market and availability are both negatively impacted when security-focused guys rule. In their job description, there is *insane* risk associated with ever saying 'yes', and generally not much risk associated with saying 'no'. They also know damn well that for all their effort, they will *not* get the whole picture, whether the team being reviewed intends to or not, they will never catch all the poor security decisions, further driving them to be paranoid in hopes they mitigate everything the company does in the hopes of catching the mistake in general roadblocks.
The general corporate reality of 'external' security teams reviewing the efforts of 'non-security' teams leaves a lot of room for the worst of security policies inhibiting productivity and of insecure design getting through that the security team is going to be oblivious to. The answer is an embedded understanding of security principles in the day to day, but that truth is too inconvenient as that is quite an expensive proposition. They want to take unskilled folks and duct tape security on by having a small band of security 'experts' tick a checkbox in the process.
blame Microsoft instead of the low horsepower hardware.
Well, I don't think it would pan out *that* way, as their more powerful gaming machines almost certainly also run Microsoft software.
However, chromebooks do have a reputation for being crappy, and no small part of it is the hardware. Microsoft proving their stuff can also run crappy will erase any vague belief that ChromeOS is the cause of the crappiness.
Of course, ChromeOS as software isn't very good, limiting and some definite software issues.
No, it's saying if you are building a runway, it would be wise to try to be angled at the center of an interval, rather than right at the edge of an interval. If it is going to round to 190, then try to exactly be 190, and then it's very tolerant to fluctuations and still be accurate enough.
Slashdot Mirror
Now when a security update comes for a core library, now I get to update every single snap instead of just updating the system library...
Yay for static linking, I mean containers....
Eggplant is usually associated with penis, so saying someone likes to eat penis is making assertions about their sex life.
Basically, using slang emoji is just like using slang words, and inappropriate use can be defamatory and/or offensive.
If I lookup U+1F346, then I'll get that it means 'AUBERGINE'.
It will not say it means 'penis', which is what it means 99.9% of the time when actually used.
Good thing you included that ':-P', otherwise that might have been seen as a threat of malicious lawsuit.
A feeling can also add something. So if I make a comment and include a feeling that adds a sort of 'wink wink, nudge nudge say no more' to a normal statement, that can be offensive.
Also, 'emoticon' started as ways to add facial expressions, and as they progressed to 'emoji' it became about ideograms as well, to state things that are concrete absent of emotion.
For example, If someone was trying to plan a lunch, and asked me what I thought a coworkers favorite food was, and I replied with an Eggplant emoji, then that could be harassment and/or defamatory.
In the cited example, it was the emotion that made it *not* defamation. If taken as serious, it might have been defamatory, but the emoji declaring it as a joke was how it was made *not* defamatory.
IPSec doesn't add anything if the peer is the thing to be compromised. That's pretty much the challenge. If things *do* get into your precious internal network, it's malware running on legitimately authenticated systems.
Physical attacks against ethernet ports are nothing compared to how often remote exploits occur.
For security to actually *work*, this is the key thing that must change.
Security in this industry has been about security teams covering their asses, it's not *their* fault if all their efforts to make things secure are bypassed by people trying to get their job done. Security *needs* to be more about understanding the human consequences of the approach being taken.
Yes, this is the whole "shadow IT" thing. Official IT falls short, people wanting to get work done will start supporting each other in creative ways. *Those* well-meaning efforts end up causing the network to be more at risk than if the IT department were more "risky" and actually helped work get done.
So my work set up OTP authentication to get in remotely.
First time around, hadware tokens. Problem: people kept losing them.
Eventually, migrate to OTP for phone use. Problem, people would forget their phones.
Ultimate solution, a website to generate the token that's publicly accessible, that just accepts the same single username/password that they were trying to get away from in the first place.
Anyone in the industry knows *exactly* what'll happen when you inconvenience people with onerous security, they bypass it. Have no viable way to exchange large files? Those files *will* end up publicly shared on google drive. Refuse to set up an internet facing service for some department in a timely fashion? Someone in that department will buy an AWS instance and just do it themself, even if they use a few dollars of their personal money.
Security is about more than locking down access to stuff, it's about facilitating work to be done securely, but within reason. Sometimes that means doing something that isn't perhaps *as* locked down as you would like, but it is better than the alternative.
However, security must also acknowledge reality. The reality is that so long as you empower your employees to do, well, much of anything, they will become potential vectors of an attack. Lock them down to be harmless, they will often also be unable to be productive.
It is worth noting that many of these attacks that happen still do happen because someone dangled part of the information outside the defenses. An improperly set up cloud storage or service has become a frequent source of compromise. These attacks would be rarer in the 'castle and moat' because they happened inside a more protected network. Sure, they shouldn't have been configured that way even internally, but reality is *someone* is going to do something like this, and better for it to be mitigated than in the open.
So the lesson is sure, be as vigiliant as you already *should* have been, but also that going out of the moat is part of the problem, not that the moat is losing efficacy compared to before.
The problem is it is out of gnome shell's hands in wayland. in X they have a responsibility, but that responsibility isn't core to the applications working.
In Wayland architecture, gnome shell is basically the X server. Now they could do a better job segregating their code and have a more bulletproof core to be the wayland compositor, but it's just a whole new role they had never had to handle in the past.
Actually, for executing a remote application, Wayland can accomodate with Xwayland.
Here the thing is sharing your screen, like in a teleconference situation or accessing your whole screen remotely rather than X forwarding which Wayland can't accommodate, in part due to intentional design decisions to mitigate security risks.
Well, it's a bit more than that. The statement has been in various circles 'wayland is good enough *today*, you don't need xorg anymore'
This is acceptance that people do have things they can't do in Wayland, and it needs to be opt-in rather than opt-opt to avoid bad user experience.
It's not 'wayland will *never* be better', but it is a statement that it has a ways to go, and some of the limitations are design choices that will require interesting conversations, particularly about security with regards to screen sharing.
It bears a much closer resemblance to texture processing in 3d modeling apps.There may be other specific domains that have this sort of approach, but web development is certainly not one of them.
Glad to see someone highlighting that beyond brand, additionally product lines matter greatly. All of those vendors also produce exceptionally crappy laptops for low price point, so you have to stick to the 'professional' lines to have a product they are not half-assing.
One, the other big notable accident was also with a vehicle with high ground clearance. At the time it was suggested that the system sensors were basically counting on something relatively close to the ground, and would miss things as they approach 'decaptiation level'.
I will say I am highly skeptical that the car slammed in at full 65 mph into a stopped fire truck. I got rear ended while I was going about 15 mph (traffic jam) by a car that was going about 60, and there were injuries and both cars were in much worse shape than the Tesla pictured (both cars totaled, frames bent so bad that no doors able to open without prybars), and that's with both cars having crumple zones, whereas the fire truck didn't yield much at all and the Tesla had to take the vast majority of the energy of the impact. Also, the Model S is a pretty heavy car, so there had to be a lot of energy in that collision.
One amendment I'd make is for worker's comp. I'll agree one should not be *dependent* upon the employer, but on the other hand there does need to be an ever present knob to twist to have companies self-interest align with worker safety (hazardous environment in theory should translate to higher worker's comp premiums).
The health insurance linked to employer is just bonkers.
The reality is that if they *did* continue the macbook air, it'd follow the same design decisions that the Macbook and Macbook pro did.
The raison d'etre for the macbook air was to have a really skinny laptop, even if it meant compromising on functionality compared to the Macbook when it was released.
Now, they've made all their lines skinny and decided not to bother doing any 'non-air' designs for more power, so air is redundant.
Since Apple is clearly not caring about your opinion anymore, maybe it's time to return the favor and shop elsewhere?
Problem is that if you are doing commercial software as a newcomer, you'll *also* want to go subscription. Subscription is more viable and it means that you have increased likelihood of future revenue even if you sit on your ass and do nothing.
It's consumer-hostile, but those that engage in it are going to out-resource those that do the right thing by the customer in the long run. In some circles, the community doing open source can overturn it, but I wouldn't expect professional competition to provide the answer.
Adobe has a stranglehold on that market, and they can pretty much do whatever they want. They realized that people weren't bothering to buy new versions, and as such their revenue was threatened, so they changed course to a subscription, to guarantee future revenue, unless a competitor came in. No competitors in sight and given the state of software today, it is highly unlikely that another vendor would choose a non-subscription path. I get everything I want out of GIMP personally, so I'm not too personally invested in that per se, but it does serve as an inspiration to all sorts of software vendors as a 'I can't make customers pay for new function, and I can't branch into new markets competently, so I can make them rent the same old software to get revenue and as a bonus, I don't have to work as hard to innovate'.
Hyperbole aside, this isn't new to 'DevOps', though I will admit that in some circles it blesses the thought process.
For as long as humans have been doing things, processes in bad groups devolve to this sort of blind and mad grasping at 'productivity', and devolving into spending more time fretting about the process of seeing if work is being done than actually doing the work. Each fad promising to 'correct' the ratio of overhead of the previous fad, either never realizing or intentionally ignoring the reality that people are the problem and will pervert any methodology that purports to fix it.
Meanwhile, good teams operating within good larger organizations will succeed with whatever project management/development fad they nominally use.
less than a quarter of respondents strongly agree that senior management understands the importance of not sacrificing security for time-to-market success.
So the problem is that senior management may understand, and the answer is not one that security experts like. Financially speaking, it may make sense to be a little fast and loose with security, or at least faster and looser than hardline security guys want. Security problems represent a liability, and for some cases not much liability, some times it *could* ruin your company, depending on what sort of company you are, the data you have, and which part of the data could be hypothetically compromised by the subsystem at hand. These have to be weighed against the cost of prevention both in terms of staffing/consulting and opportunity cost when your paranoia causes you to not implement a scary feature that your competitor does, or to be a year later than a competitor.
Complicating things, there's a disconnect between paranoid security practices and where the largest breaches come from. The vast majority of breaches come from someone putting a crappy credential on something. This is overwhelmingly bad practice and overwhelmingly basic. The reaction to a breach in the industry is for security guys to use it to go to town, enforcing more and more draconian limitations using more and more inscrutable approaches to mitigate risk, even though the existing processes would have already defended them adequately if applied correctly. It's like never taking a shower because you keep reading about people drowning in the ocean. There's not the risk in your shower, but water-related death is a thing, so why take a chance.
Meanwhile, time to market and availability are both negatively impacted when security-focused guys rule. In their job description, there is *insane* risk associated with ever saying 'yes', and generally not much risk associated with saying 'no'. They also know damn well that for all their effort, they will *not* get the whole picture, whether the team being reviewed intends to or not, they will never catch all the poor security decisions, further driving them to be paranoid in hopes they mitigate everything the company does in the hopes of catching the mistake in general roadblocks.
The general corporate reality of 'external' security teams reviewing the efforts of 'non-security' teams leaves a lot of room for the worst of security policies inhibiting productivity and of insecure design getting through that the security team is going to be oblivious to. The answer is an embedded understanding of security principles in the day to day, but that truth is too inconvenient as that is quite an expensive proposition. They want to take unskilled folks and duct tape security on by having a small band of security 'experts' tick a checkbox in the process.
blame Microsoft instead of the low horsepower hardware.
Well, I don't think it would pan out *that* way, as their more powerful gaming machines almost certainly also run Microsoft software.
However, chromebooks do have a reputation for being crappy, and no small part of it is the hardware. Microsoft proving their stuff can also run crappy will erase any vague belief that ChromeOS is the cause of the crappiness.
Of course, ChromeOS as software isn't very good, limiting and some definite software issues.
No, it's saying if you are building a runway, it would be wise to try to be angled at the center of an interval, rather than right at the edge of an interval. If it is going to round to 190, then try to exactly be 190, and then it's very tolerant to fluctuations and still be accurate enough.