Live data from Hacker News

Coreutils for Windows

github.com

31–40 of 260 posts

Re: Coreutils for Windows

#32
post #13

Earlier quoted context omitted.

From shred man: The shred command relies on a crucial assumption: that the file system and hardware overwrite data in place. ... many modern file system designs do not satisfy this assumption. Exceptions include: ... Log-structured or journaled file systems, such as. ... NTFS.

I think SSDs also randomize where data ends up? But I'm not sure if that's true for existing files too.

The filesystem may choose to store new data at different logical block addresses than older versions. The SSD will definitely choose to store those newly written blocks at different physical addresses, both for the sake of wear leveling and for performance, because a read-erase-rearite cycle on an entire NAND flash erase block (several MB at minimum) is a very slow operation.

Re: Coreutils for Windows

#33
post #27
post #13

Earlier quoted context omitted.

I think SSDs also randomize where data ends up? But I'm not sure if that's true for existing files too.

Yes. All of the assumptions made with shred and sdelete apply only for spinning HDDs. SSDs require different methods of wiping.

Is there no way to track down where the data actually lives?

Re: Coreutils for Windows

#36

Was not expecting EEE for Coreutils but I suppose it’s the natural consequence of the MIT license used for uutils so not totally unexpected. It’s annoying enough to support the differences between BSD and Linux, and now Linux has GNU and uutils, and now we’re gonna need Windows variant of uutils…ugh.

It was really obvious.

Microsoft "loves" Linux for years and the entire point was to bring the Linux userspace on the Windows Desktop.

Re: Coreutils for Windows

#37

Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes. Or better yet, just switch everything to full POSIX. In powershell everything is much better than cmd, but it's just not enough. WSL is generally great, but there are annoying downsides. I often get "catastrophic" crashes and the zone identifier files drive me nuts. Plus it takes so much longer to start VSCode when con…

the two filesystems can be a super power... i seamlessly use the same driver between wsl2 and my dual booted opensuse.

Re: Coreutils for Windows

#38
I would have liked to see head, tail, tr, uniq, and cut. I end up dragging over the old "gnuwin32" versions of those to a lot of Windows machines. Those are my go-to tools for quick-and-dirty log analysis.

I know I could use Powershell for those kinds of tasks, and I certainly do make a lot of use of Powershell, but the familiarity of those simple tools and the decades-old "muscle memory" of using them on various Unix, Linux, and Windows boxes makes them hard to ditch.

Re: Coreutils for Windows

#39
post #24
post #6

So dir is not shipped due to conflict with built-ins, echo and rmdir are shipped despite conflicts, and sort is deemed not to have a conflict? What is the logic?

No idea, this is broken at start, I would expect at least a reasoning on how they expect to improve the mess going forward. Otherwise just don't do it, if it is going to be a mess to work with.

There's almost no point to this, especially since they're already shipping a (strictly) limited subset with the reasoning "not useful on Windows" despite Windows equivalent facilities _clearly_ existing. They should have at least considered a full native port.

Re: Coreutils for Windows

#40

Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes. Or better yet, just switch everything to full POSIX. In powershell everything is much better than cmd, but it's just not enough. WSL is generally great, but there are annoying downsides. I often get "catastrophic" crashes and the zone identifier files drive me nuts. Plus it takes so much longer to start VSCode when con…

>Windows really needs to ditch CRLF...

Windows needs to ditch itself.

Post reply on HN