Forgot your password?
typodupeerror

Comment They'd serve different purposes. (Score 2) 11

A balloon is not static, it moves with the atmospheric system it is in. Ergo, it tells you how that system evolves. A drone cannot do this.

A drone can stay put, relative to the ground, telling you how a location's atmosphere evolves. A balloon cannot do this.

These are solving completely different types of problem.

You could, of course, construct a hybrid, as balloons are traditionally single-shot. If a balloon carries the measurement gear and a drone capable of carrying that same gear PLUS a deflated balloon, then you can have something that operates as a balloon until it reaches some pre-set location, whereupon the balloon's gas is released and the drone flies the ensemble to a collection point.

Comment How much safety does this give? (Score 1) 1

It obviously gives us guarantees in terms of what the source will do and what the compiled code should need.

These do not provide memory safety, so memory bugs would not be solved by these. They will find unexpected behavioural issues, though.

The precondition and postcondition statements are not cunningly-disguised assert statements because they're not asserted at runtime. They're enforced at static check and/or compile time.

The policy hints mean that if the kernel is doing something you're not expecting, you find this when testing the code. Equally, though, it means that users cannot cause the software to venture into realms unknown through many of the usual attack vectors because those will require permissions that aren't there.

Submission + - FBI gets voter's IP address in new fraud probe tactic (axios.com)

alternative_right writes: The Trump administration has a new tactic for trying to isolate cases of alleged voter fraud â" digging into the IP addresses of those who went online to register to vote.

The FBI recently obtained the IP address of someone who registered online in South Carolina, according to documents first shared with Axios.

User Journal

Journal Journal: How to improve C/C++ code quality, random thoughts 1

I am thinking about the following concept. Take doxygen comments and extend them as follows.

1. Permit identification of pre-conditions for functions (what has to be true when the function is called)
2. Permit identification of post-conditions for functions (what is intended to be true when the function exits)
3. Permit identification of hints about what kernel operations are being used by that function

Comment Re: Honesty (Score 1) 106

A late reply to your comment:

Yes, overall structure is a problem. I generally give it hints as to how I would like the architecture to be, and for larger projects I mention that future ability to expand/extend is important, which then makes it construct more robust "frameworks".

But generally you need to know what the bones of your solution should look like and push it in that direction otherwise you end up with nicely commented spaghetti code.

Comment As designed (Score 1) 182

Function did its job, exactly as designed.

Whether it's legal to use or not is dependent on jurisdiction and circumstances (and still hasn't been established!), but the function existing and allowing a user to use it is no bad thing.

Think a mugger demanding you access your bank accounts. Oh, no, look, the phone's stopped working...

Comment BKL (Score 1) 30

It's like a miniature version of the "big kernel lock" thing that took years to resolve.

Sure there were some blocking issues causing performance setbacks for it in certain locations but it was orders of magnitude more difficult to slice it out and replace things with smaller locks, and it still didn't have MASSIVE increases in performance or any user-visible way at all.

It's just code maintenance.

Comment Re:Your heart surgeon in 19 years (Score 1) 132

The barrier to AI cheating is ridiculously low, though.

RIDICULOUSLY LOW.

It tool me about 20 seconds to paste your comment into Claude and get this back out:

Quick take, then the rebuttal itself:
 
The comment's "cheaters gonna cheat" logic dodges the actual point. A few counters:
 
Ease changes behavior, not just outcomes. If AI cheating is dramatically easier and lower-risk than pre-AI alternatives (crib notes, bribing a proctor, memorizing leaked exams), it doesn't just help existing cheaters - it recruits new ones who wouldn't have bothered with the harder, riskier methods. Frictionless cheating scales.
 
"Someone would've cheated anyway" doesn't mean the tool is blameless. That's true of almost any enabling technology (fake IDs, counterfeit currency, doping). We don't shrug at those because determined bad actors exist regardless - we still try to close the specific hole.
 
The "other tests exist" point is the real concession. If proctored, in-person, or oral exams resist AI cheating better, that's an argument for changing how we test, not for waving away AI's role in why the change is suddenly urgent. The heart surgeon example works against the poster here - we'd absolutely want to know an AI-era certification exam let someone through who couldn't do the job, because the failure mode (unqualified surgeon) is real regardless of how they cheated.
 
So the response isn't "AI is uniquely evil," it's "AI meaningfully lowered the cost of cheating, which is exactly why testing methods need to adapt" which is compatible with, not contradicted by, the original comment's own second paragraph

Comment Re:Plausible deniability is better (Score 1) 218

On the other hand, it is actually common to make the duress password VERY similar to the correct password so it looks about the same when you enter it. Especially on something like a phone where you can generally re-load the data later if you want. The consequences of an accidental wipe may be quite small.

Other posible explanations include the defendant remembering the wrong password under pressure. The defendant having any history of mis-typing is irrelevant.

Slashdot Top Deals

If I'd known computer science was going to be like this, I'd never have given up being a rock 'n' roll star. -- G. Hirst

Working...