ChrisSD

But when that leap minute does eventually occur, it's going to cause havoc in all the systems that don't handle it. Which, let's face it, there are going to be a lot of. Either because they were never designed for it or else the relevant code paths were never actually tested.

And it has mutable aliasing via `UnsafeCell`[0] which, as the name says, is unsafe. But safe wrappers can be built around it, such as `Cell`[1]. Or you can just use raw pointers and take safety into your own hands.

[0]: https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html

[1]: https://doc.rust-lang.org/std/cell/struct.Cell.html

Ok, I committed some mild linker crimes and got the same program down to 800 bytes.

   rustc hello.rs -C panic=abort -C opt-level=3 -C link-args="/ENTRY:main /DEBUG:NONE /EMITPOGOPHASEINFO /EMITTOOLVERSIONINFO:NO /ALIGN:16"

A similar program on Windows is 3072 bytes. I compiled it using:

    rustc hello.rs -C panic=abort -C opt-level=3 -C link-arg=/entry:main

Here's the program:

    #![no_std]
    #![no_main]

    #[panic_handler]
    fn panic_handler(_panic: &core::panic::PanicInfo<'_>) -> ! {
        unsafe { ExitProcess(111) };
    }

    #[no_mangle]
    pub extern "C" fn main() -> u32 {
        let msg = b"Hello, world!\n";
        unsafe {
            let stdout = GetStdHandle(-11);
            let mut written = 0;
            WriteFile(
                stdout,
                msg.as_ptr(),
                msg.len() as u32,
                &mut written,
                core::ptr::null_mut(),
            );
        }
        0
    }

    #[link(name = "kernel32")]
    extern "system" {
        fn ExitProcess(uExitCode: u32) -> !;
        fn GetStdHandle(nStdHandle: i32) -> isize;
        fn WriteFile(
            hFile: isize,
            lpBuffer: *const u8,
            nNumberOfBytesToWrite: u32,
            lpNumberOfBytesWritten: *mut u32,
            lpOverlapped: *mut (),
        ) -> i32;
    }

I didn't bother much with the panic handler because there's no reason to in hello world. Though the binary contains a fair bit of padding still so it could have a few more things added to it without increasing the size. Alternatively I could shrink it a bit further by doing crimes but I'm not sure there's much point.

It may be worth noting that the associated pdb (aka debug database) is 208,896 bytes.

> Of what use is a filesystem with many empty files? You could use it to benchmark things that do things to all the files in a directory tree. For example, what is the fastest way to list all those files? Delete them? Back them up? Create an archive file with all of them?

This can be useful up to a point. But be careful of over optimizing for the pathological case at the expense of typical usage. Most of the listed operations are usually done on a small number of files. And even when they seem a lot to the user it's still a teeny tiny fraction of one billion.

And that's before we even mention directories.

Just to clarify, I doubt many people from the UK would know off hand what CBE stands for even though they know what a CBE is. The full name is pretty archaic in any case so it's basically just trivia at this point.

The opt-in is only required if they collect your information. If they take the default as opt-out then they don't have to show you any prompt and have no liability.

If you think nobody complains about Rust then you haven't visited HN much recently ;). Heck, Bjarne Stroustrup himself has recently taken to complaining about Rust in papers and talks (though most recently he's taken to referring to it without naming names).

> Complicating this picture is shells. For a long time, many shells have kept track of a name for their current directory themselves, often materializing this in the '$PWD' environment variable. The shell has to keep track of this name as a text string or the rough equivalent, which makes it potentially less accurate than the kernel's version. However, it has some advantages, because unlike the kernel, the shell knows what name you typed in order to get to the directory, which may not be the actual filesystem name of the directory because of things like symbolic links. Shells often use this knowledge so that names like '..' and even '.' work on the text version, not the filesystem version.

Related reading: Lexical File Names in Plan 9 or Getting Dot-Dot Right (https://9p.io/sys/doc/lexnames.html)

I'm not sure I understand. Why would rebasing ever be more complicated? They're the same thing at the end of the day, no? Main branch and my branch both changed this line no matter what, you must resolve that conflict.

IIRC, Python managed to move to github issues.

1993

Code signing wouldn't necessarily fix that. There are a lot of "legitimate" applications that a user wouldn't want. For example, spyware is fine if there's some plausible deniability to it because many applications do some form of spying nowadays.

> While the game is a bit on the short side, there's enough depth to its mechanics to feel satisfying to master, and the realization that a game that gave you so much trouble at first has turned into a total cakewalk can't be matched.

Yeah, if I recall, once you figure out all its mechanics you are able to hack anything in about a month of game time. This is marvelous once but obviously does hurt replayability.

It is fun to think I can never really replay uplink, short of some rather severe amnesia.

Much speed up was from using the right data structure for the task, e.g. Vec rather than HashMap and BitSet rather than HashSet.

No it's basically "how to analyse and improve the performance of Rust code" with a "btw, I prototype in python".

They did swap the hashing function

> Note that everywhere we refer to HashMap is actually an alias for fxhash::FxHashMap, which is just std::collections::HashMap with a more efficient hashing algorithm

It does. But this issue arises because of file locks. Running an executable holds a lock that prevents deletions (but not renames).

Many OSes have file locks, though they often don't use them as liberally as Windows.

Notably Rust's standard library does allow deleting files it opens by default. https://github.com/rust-lang/rust/blob/735bb7e5df185cc24e565...

While full Unix-like behaviour is only available on Windows 10 for the past five or so years, you can still have the old win32 behaviour on older systems (delete once the last file handle is closed).

The fact it injects into another process means they can't know if it'll crash or not. You're just one Explorer update away from things changing enough for the hack to crash it.

I guess they could do this more robustly. I.e pause the entire explorer process, save all its state, remotely allocate new memory to inject their code, remotely create a new thread, run only that thread using the injected code, restore all the process' state and finally start it running where it left off. A script would be easier though.

It's not really a security measure in that sense. It's a "safety feature" that prevents accidentally running such a script. Anything can trivially disable the protection using a bat script (or anything else) to bootstrap.

E.g. `powershell.exe -ExecutionPolicy Unrestricted`

It has little to do with the filesystem. Windows has OS level locks. In the case of a running executable, the mapped memory holds a lock on the exe file to prevent deleting it. This is intentional. If it didn't hold the lock then it would be possible to delete the exe file on modern versions of Windows.

Edit: since there still seems to be confusion I'll try to be clearer. On NTFS you can delete an open file. This is a solved problem. The DeleteFile API even does this by default now. The thing that prevents deletion is an OS lock. This lock only prevents deletion. Renames are still allowed.

No their stance is to create RFC#3463[0] setting out a policy for handling name squatting and other issues. What they won't do is act unilaterally without a policy and accountability.

[0]: https://github.com/Turbo87/rust-rfcs/blob/crates-io-policy-u...

Except that means tools aren't doing "one thing" as in the Unix philosophy. Or least I know of very few unix tools that actually do that. At a minimum they need to bundle an argument parser (or more often reinvent their own). They also need to do the same for generating output, often in multiple different display formats depending on the precise flags used.

And I think your overstating the contract argument. If `ls` changed its output format in any way (unless behind a flag) it'd break a heck of a lot of bash scripts. With a well structured output format it's better able to maintain backwards compatibility while adding new features.

So long as a tool can output a machine readable format, it can be consumed by nushell. If it can't then... that's actually a big problem when composing tools in bash too. Parsing arbitrary unstructured text is not good for composition and requires making something bespoke for each and every tool. As well as each and every argument for each and every tool for those arguments that happen to change the output in different ways.

But saying things like "everything is somewhere in the middle" and "use common sense" is just as much marketing speak. It's meaningless to the point it's very successfully used in both marketing and politics (but I repeat myself).

The key thing is you can set the parameters so that whatever you're selling happens to fall squarely in the middle. And of course anything can be common sense so long as you can successfully ridicule the alternatives and describe your solution in a way that sounds plausible(ish).

So for those that only skimmed, the problem here is bridging the gap between native Windows and Cygwin's POSIX emulation (which is a "terrible impedance mismatch"). This is made more difficult because Cygwin's Unix socket emulation is a "kind of awful"[0] undocumented protocol.

[0]: https://stackoverflow.com/questions/23086038/what-mechanism-...

I wonder if that legal theory has ever been tested? I admit I'm sceptical that it would hold up in court.

Right, but my point is that "Program Files" &co were so common that it forced IT people (and everybody else) to handle this correctly. Executing something one level up is not the kind of bug that's going to be unnoticed when it'll be hit so often.

(btw most IT folks prefer powershell, if only because all the management tools are powershell modules)

On Unix perhaps. Windows forced IT folks to deal with the issue by having folders like "Program Files". Even the user's folder used to be in "Documents and Settings" (but they backed down from that eventually and now it's just "Users").