Anecdotally? I always found Windows to be worse when it comes to disk life. It idles much more rarely and infrequently than Linux will.

GhostBSD isn't Linux either. :p

Fundamentally it's the same in all the major OSes: if the disk isn't being accessed, it'll be idle. If it's idle long enough, it'll also have its heads parked and actually stop moving. If you witness anything else, that means the disk is being accessed by some process somewhere.

GhostBSD isn't Linux either. :p

It is FreeBSD, no?

I fear that when a disk drive motor isn't correctly stopped, the changes to the filesystem inside wouldn't get saved and files would get corrupted.

It is FreeBSD, no?

based on FreeBSD yeah

I already used Debian in FreeBSD and Mach variants.

I fear that when a disk drive motor isn't correctly stopped, the changes to the filesystem inside wouldn't get saved and files would get corrupted.

It happens infrequently, but it can happen. This is part of why ZFS was made: to guarantee things are what they say they are.

Well, non-Linux Debian is trash.

Indeed. Maybe fun experiment. Maybe useful if HURD ever becomes useful. As for kFreeBSD, might as well just use FreeBSD.

Make the ultimate abomination: Debian GNU/kReactOS

I fear that when a disk drive motor isn't correctly stopped, the changes to the filesystem inside wouldn't get saved and files would get corrupted.

believe me or not, this has happened to me countless of times already on freeBSD, I've tried to drag a folder into an hard drive and then I grabbed the hard drive cord to remove it out from the USB slot. the changes to the file dissapeared and nothing would get written. If I did the same thing on windows; the file would still remain on a disk even if it has been written once.

Make the ultimate abomination: Debian GNU/kReactOS

With the powerfull Wine Shell

believe me or not, this has happened to me countless of times already on freeBSD, I've tried to drag a folder into an hard drive and then I grabbed the hard drive cord to remove it out from the USB slot. the changes to the file dissapeared and nothing would get written. If I did the same thing on windows; the file would still remain on a disk even if it has been written once.

I don't know what are these additional processes windows is doing compared to other operating systems

believe me or not, this has happened to me countless of times already on freeBSD, I've tried to drag a folder into an hard drive and then I grabbed the hard drive cord to remove it out from the USB slot. the changes to the file dissapeared and nothing would get written. If I did the same thing on windows; the file would still remain on a disk even if it has been written once.

Two things: Actually eject the drive. The command/program won't return and give you the OK until all the data is written. Linux/FreeBSD prefer to treat all file systems equally by default, which is to give the best performance especially for long-term mounts. They're mounted async by default, so your writes will happen as fast as it can enter your RAM. It'll eventually make it to the storage medium as quickly as that could happen. Windows treats USB drives in sync mode only. Sure your writes are slow, but your files are more likely to be there if you suddenly yank the thing. ("More likely", not guaranteed, mind)

You can replicate the exact same behavior on Linux and FreeBSD by mounting it in sync mode.

Also you really shouldn't yank drives no matter the OS :) The file system won't be in a nice state.

I don't know what are these additional processes windows is doing compared to other operating systems

Windows tends to do a lot of things in the background. To highlight, I can say that it does disk defragmentation, downloads automagical updates and bugs the indexing system to an infinite loop.

You can replicate the exact same behavior on Linux and FreeBSD by mounting it in sync mode.

wow! I need to try it someday. I may as well need to find a different shell on freeBSD that mimicks some important file features from NT.

Your complaints probably have nothing to do with the shell at all.

Also you really shouldn't yank drives no matter the OS :) The file system won't be in a nice state.

never, always never.

I think BTRFS and ZFS are the two filesystems that implement many features of NTFS and more.

Eh, you can just use UFS or ext4 for file systems that implement "many features of NTFS" ZFS and btrfs are a whole different ball game entirely.

Your complaints probably have nothing to do with the shell at all.

don't know the cause. GhostBSD is an amalgamation of things.

ZFS is all about extreme care for consistency even in the face of bad hardware (storage devices especially). btrfs kind of copies ZFS but does it worse.

I mean, ZFS is also designed so if you have a ZFS pool on a USB drive, simply yanking it will still keep you with a consistent file system. Probably not with all the latest writes you did to it, but avoiding corruption nonetheless.

Eh, you can just use UFS or ext4 for file systems that implement "many features of NTFS" ZFS and btrfs are a whole different ball game entirely.

I already use ufs as my home folder partition style. maybe zfs Is better for archivial purphoses but I did already tried it in the past as my home folder partition setup and I've ended up with slowdowns

The main feature of NTFS that ext4 and btrfs lack are rich ACLs. UFS and ZFS have them, and if you run FreeBSD, you'll get the full set of ACLs that NTFS has plus a few more.

ZFS is all about extreme care for consistency even in the face of bad hardware (storage devices especially). btrfs kind of copies ZFS but does it worse.

One advantage of BTRFS over ZFS is that it needs much less RAM to use the file system. For ZFS, it is recommended to have at least 8 GB of RAM for acceptable performance. Another advantage of BTRFS is that it allows handling files without the CoW system, which can be useful in some cases.

I already use ufs as my home folder partition style. maybe zfs Is better for archivial purphoses but I did already tried it in the past as my home folder partition setup and I've ended up with slowdowns

UFS is the old school style of file system. Simple pointers and simple streams of data. It's in the same class of FS that NTFS and ext4 live in. Due to its simplicity, it does basically let you go as fast as your disk lets you. ZFS is a whole other ball game. Everything is copy-on-write so nothing is overwritten in place, multiple levels of indirection pointers are used to achieve it. It's safe, but safety comes at a performance cost. (not much of one, mind, but it exists)

The problem with BTRFS is that it has a lot of experimental features.

UFS is the old school style of file system. Simple pointers and simple streams of data. It's in the same class of FS that NTFS and ext4 live in. Due to its simplicity, it does basically let you go as fast as your disk lets you. ZFS is a whole other ball game. Everything is copy-on-write so nothing is overwritten in place, multiple levels of indirection pointers are used to achieve it. It's safe, but safety comes at a performance cost. (not much of one, mind, but it exists)

ok, thank you for the detailed explanation. I'll give you a golden medal

It's a birds-eye view explanation. I try to be simple enough to understand from scratch without going into all the details :)

The problem with BTRFS is that it has a lot of experimental features.

btrfs (which is written all lowercase, mind :P) suffers deeper problems than that, and they stem from bad management in all honesty. Linus Torvalds was dumb enough to run btrfs on his computer when all the warning flags were still there about it being experimental at al. Got angry when btrfs devs decided that a disk format change was required to support features they wanted, forced a revert and frozen disk format when it should never have been frozen. btrfs is pretty much stuck with a bad design forever because of Linus.

It's been in development since 2008 and still nowhere near stable. That's 15 years ago. By comparison, ZFS started development in late 2000 and its first stable release happened in late 2005. Experiments were done in that time, disk formats were finalized. It has a good and proper design that's held up.

last thing I have yet to understand it's the signal microsoft operating system sends in order to tell the internal motor to slowdown and stop moving. What else it does when it carries over an usb wire?

I think there is a low-level command to send to USB MSDs that ask them to finish all operations. Whether that's done is up to the firmware on the USB drive. :p

in short: all drives lie, and USB drives lie the most. Especially the cheap ones.

what about SATA drives? Do they lie too?

All drives.

That was Jeff Bonwick's motivation for creating ZFS: noticing that drives would simply say everything was fine when it clearly was not. So ZFS uses copy-on-write to never overwrite data in place, and checksums everywhere. And ideally, you use ZFS in mirrored or raidz configurations to survive following a disk lying (or just going bad/dead).

At least, that was half the motivation. The other half was wanting to make adding storage as easy as adding RAM. Need more memory? Just put sticks in. Need more disk space? Add disks, then mess with partitions and volume managers, and resize stuff.... "oh forget that, I'll make ZFS where it becomes as easy as 'Just put disks in' "

what tool can we use on freeBSD that can mimick the batch-renaming features of windows file manager (linux already has one, but it's complex and the last time I've tried it I ended up altering file extensions the wrong way causing me to fall into many problems and I'm still recovering to this day)?

You'll have to look for one. I neither have an answer, nor is this a FreeBSD channel.

You might try FreeBSD forums as an avenue for the query.

not an easy feat when others misunderstand your questions all the time.

My programs are memory hunger.

not an easy feat when others misunderstand your questions all the time.

There's a rename in ports. That's probably what you want (could be the same program you get on Linux distros)

not an easy feat when others misunderstand your questions all the time.

the windows way of doing things on unix-like systems cannot always be emulated and you must try different approaches to suit your needs. I often move files between different operating systems and it's a complex problem that it's not an easy thing to resolve, I hope that I can do the best I can no matter how large the problem is.

Perfect. 👌

There's a rename in ports. That's probably what you want (could be the same program you get on Linux distros)

can I see the freeBSD repository entry of this program pretty please?

believe me or not, this has happened to me countless of times already on freeBSD, I've tried to drag a folder into an hard drive and then I grabbed the hard drive cord to remove it out from the USB slot. the changes to the file dissapeared and nothing would get written. If I did the same thing on windows; the file would still remain on a disk even if it has been written once.

When you request a write, it doesn't write directly. A filesystem such as ext4, Btrfs, has Allocate-on-flush feature. It also identics to Berkeley's UFS block reallocation. The more commit time, the more longer it gets flushed. It also can reduce disk fragmentation.

Hence which is why NTFS is not recommend for USB thumb drive https://devblogs.microsoft.com/oldnewthing/20130101-00/?p=5673

Sharing stuff between Windows computers via an NTFS drive is just an exercise in pain :p

unless everyone is on the same AD network, ACLs will be a constant hinderance.

do the smart thing and use exFAT

Sharing stuff between Windows computers via an NTFS drive is just an exercise in pain :p

Even with the new kernel NTFS driver?

The driver isn't the problem

It's a simple matter of file ownership and permissions.

https://twitter.com/reactos/status/1626690338067828751

https://twitter.com/reactos/status/1627027865241022464

https://twitter.com/reactos/status/1627402388049911812

Intel Open-Sources Its OpenCL CPU-Based Runtime - Phoronix https://www.phoronix.com/news/Intel-OpenCL-CPU-Open-Source

Intel Open-Sources Its OpenCL CPU-Based Runtime - Phoronix https://www.phoronix.com/news/Intel-OpenCL-CPU-Open-Source

https://twitter.com/keita_krizantem/status/1627302656636243968 @ctasan

https://twitter.com/PunishedGreene/status/1627203713713438721

https://twitter.com/PunishedGreene/status/1627203713713438721

lol when i see the second picture

memory leak or what?

https://twitter.com/reactos/status/1627647075507740672?s=20

wow

where did you get so many old laptops

Well, he just gets them somewhere

https://twitter.com/reactos/status/1627647075507740672?s=20

Not bad at all! Questions: is there in Reactos a switch to enable pae, like in windows? Could the tester please try either pae or x64 version? Thanks!

Not bad at all! Questions: is there in Reactos a switch to enable pae, like in windows? Could the tester please try either pae or x64 version? Thanks!

there were such PRs, but... maybe they are for 2003 kernel, and reactos kernel probably doesn't support it currently

hbelusca Z[J]=∫𝒟𝜑 exp(ⅈS[𝜑,J]/ℏ): https://www.youtube.com/watch?v=IiDvo-xTinY

hbelusca Z[J]=∫𝒟𝜑 exp(ⅈS[𝜑,J]/ℏ): https://www.youtube.com/watch?v=IiDvo-xTinY

Oh. My. O.O

hbelusca Z[J]=∫𝒟𝜑 exp(ⅈS[𝜑,J]/ℏ): https://www.youtube.com/watch?v=TnlCRoBAcuw

No ReactOS summer of code this year? 😢

Why?

Probably no one volunteered, idk