WTF Bites
-
@Zerosquare said in WTF Bites:
Yes. That's his main machine
Not my machine, but is a PLC controller that was to be sent for decommission.
I haven't had a bare-metal installation of '95 available for.... 6 years?
-
@Tsaukpaetra said in WTF Bites:
Not my machine, but is a PLC controller that was to be sent for decommission.
Please tell me it's not controlling a nuclear-grade centrifuge.
-
@Zerosquare said in WTF Bites:
@Tsaukpaetra said in WTF Bites:
Not my machine, but is a PLC controller that was to be sent for decommission.
Please tell me it's not controlling a centrifuge.
Not sure. Actually I think it was an inter-machine transfer controller? Don't know, it's gone now so I can't verify.
-
@Tsaukpaetra said in WTF Bites:
I haven't had a bare-metal installation of '95 available for.... 6 years?
I haven't had one of those since I got a machine with WinXP fairly shortly after that OS was released.
-
@TimeBandit said in WTF Bites:
On Windows 95, everyone was an admin.
Yet it kept telling you to contact the system administrator any time something went wrong.
It's called "victim-blaming" and it's a time-proven tactics.
-
@sebastian-galczynski said in WTF Bites:
There's a countdown clock on the website, counting down the time remaining until a thing happens in the system. It's broken. If I hide the tab, it starts lagging, sometimes by many minutes. But it also runs too fast sometimes. It's 2023, I guess you can't just make an approximately accurate clock like in the 1700s.
TBF that clock is free as in beer and approximately weightless. If you're looking for a clock the size of a large clock for about 10 years of your salary I can set you up with someone.
-
@Zerosquare said in WTF Bites:
@Tsaukpaetra said in WTF Bites:
Not my machine, but is a PLC controller that was to be sent for decommission.
Please tell me it's not controlling a nuclear-grade centrifuge.
You mean: the password is hard-coded?
:siemens: 
-
@Tsaukpaetra said in WTF Bites:
I haven't had a bare-metal installation of '95 available for.... 6 years?
I haven't had one of those since I got a machine with WinXP fairly shortly after that OS was released.Discovering old system installations is like Christmas sometimes.
-
@TimeBandit said in WTF Bites:
@Tsaukpaetra said in WTF Bites:
Didn't need to install to confirm.
Because of course you have a Win95 machine available
I think I might still have my original Win98 (well, it started on 95) laptop. 800x600 screen. About 2 inches thick.
Too(Pretty sure I kept it for nostalgic reasons...)
to look tho.edit: Oh my, I did find it.
That much dust - and there were things on top of it.
Place the mouse next to it for scale.
No, I didn't turn it on.
-
@Tsaukpaetra said in WTF Bites:
I haven't had a bare-metal installation of '95 available for.... 6 years?
I haven't had one of those since I got a machine with WinXP98 fairly shortly after that OS was released.
That was 25 years ago.
-
-
No, I didn't turn it on.
.... Are those gamepad buttons? That's fuckin' ballsy for a laptop with no apparent speakers.
Also, don't think I don't see that printer hiding behind it!
-
No, I didn't turn it on.
Yes. Because I (vaguely) remember how long it takes to boot.
-
@Tsaukpaetra said in WTF Bites:
Also, don't think I don't see that printer hiding behind it!
Brother HL-2230.
-
No, I didn't turn it on.
Yes. Because I (vaguely) remember how long it takes to boot.
Placing my bet at 71 seconds to desktop idle.
-
No, I didn't turn it on.
Check the pillows for seasoning. They might be at just the right spiciness level.
-
I havenāt spoken to my stepdad in 5 years but Iām fairly sure he still has his 486 laptop that he boots off floppy disk, just to use QBASIC and a honest to goodness serial port for controllingā¦ some random project.
-
486 laptop that he boots off floppy disk
Hard drives were already common long before the 486 was. Are you sure you didnāt accidentally type a 4 there?
-
486 laptop that he boots off floppy disk
Hard drives were already common long before the 486 was. Are you sure you didnāt accidentally type a 4 there?No, Iām quite sure. He has a 486-DX100 laptop that he boots off floppy disk because it came with Win98 and he doesnāt know how to make the thing boot to DOS only otherwise.
-
Place the mouse next to it for scale.
It's got a floppy drive. Some of us are
enough to know how large those were.
-
@Zecc More properly it has a diskette drive. Floppies were even larger.
-
Dear Windows, I asked you to copy files, not discover them.
Windows "discovering" the files took about as long as scp took to copy them to the network share in the first place. Windows is currently copying files at a rather leisurely pace.
Note to self: next time, just use cygwin+scp on Windows.
Any program would have to list the files, unless you just dump the whole partition image. scp would be just as slow, unless you tar all these files into one, which i'd recommend. Don't gzip them though, use scp -C instead.
-
@sebastian-galczynski said in WTF Bites:
Dear Windows, I asked you to copy files, not discover them.
Windows "discovering" the files took about as long as scp took to copy them to the network share in the first place. Windows is currently copying files at a rather leisurely pace.
Note to self: next time, just use cygwin+scp on Windows.
Any program would have to list the files, unless you just dump the whole partition image. scp would be just as slow, unless you tar all these files into one, which i'd recommend. Don't gzip them though, use scp -C instead.
tarandscpwould have to discover files all the same. Although this should never take significant time for a few 10k files at least on local file systems. This is worst-case after dropping all caches:[root@c2d1gg0 ~]# time find 2>/dev/null /home | wc -l 2037066 real 0m20.103s user 0m0.638s sys 0m3.174star+scp costs twice the I/O bandwidth. Unless you have a 10Gbps network and a lot of data where using
ncmay make sense,tar -zcf - /blah | ssh foo@bar "tar -zxf -"is fastest.
-
@LaoC Compression is cheap on all modern processors, unless you use the very fanciest algorithms (the ones that look at the whole of the data before deciding to compress anything). Streaming compression algorithms like DEFLATE are able to keep up with pretty much any network or disk hardware you might have involved.
Windows's file copy is doing something weird behind the scenes. Why does it need to make a full list of the files first? Why does that take so long?
-
@sebastian-galczynski said in WTF Bites:
Dear Windows, I asked you to copy files, not discover them.
Windows "discovering" the files took about as long as scp took to copy them to the network share in the first place. Windows is currently copying files at a rather leisurely pace.
Note to self: next time, just use cygwin+scp on Windows.
Any program would have to list the files, unless you just dump the whole partition image. scp would be just as slow, unless you tar all these files into one, which i'd recommend. Don't gzip them though, use scp -C instead.
Modern windows versions actually materialize the list, reading which source files exist, and whether any conflicting files already exist in the destination. Then if there are any conflicts it asks for confirmation. And only then it starts copying.
Linux tools do not build the full list. As they iterate through the filesystem, they copy files as they encounter them. When files are small but numerous, this leads to linux tools having completed the copy before the windows tool has written a single byte to the destination.
-
This also includes āwould the destination path be too longā and the materialisation process also involves resolving things like directory junctions for funsies.
-
tar+scp costs twice the I/O bandwidth. Unless you have a 10Gbps network and a lot of data where using nc may make sense, tar -zcf - /blah | ssh foo@bar "tar -zxf -" is fastest.
Let me introduce you to
scp -o Compression=yes. Or configure the same in~/.ssh/config.
-
@Zecc More properly it has a diskette drive. Floppies were even larger.
8 inches.
-
@LaoC Compression is cheap on all modern processors, unless you use the very fanciest algorithms (the ones that look at the whole of the data before deciding to compress anything). Streaming compression algorithms like DEFLATE are able to keep up with pretty much any network or disk hardware you might have involved.
Depends on how many cores you're able to throw at it. My i7-1270P single-thread gzips (that's the same zlib algorithm as DEFLATE) /dev/zero at ~310 MB/s, /dev/random at a mere 40 MB/s. The result of
tar -cf - /homeas some somple real-world data doesn't get much above 50MB/s. UsingpigzI can get 300 MB/s, but that's still not as much as I could push through 10 Gbps uncompressed. I just tried on a 48-core server and I get about 500 MB/s before it's presumably the disks that max out while pigz burns about 20 cores. So if you have that many, compression may be worth it. But then you still may not want to use ssh with its single-threaded encryption, which is faster than compression but may be a bottleneck, too.Windows's file copy is doing something weird behind the scenes. Why does it need to make a full list of the files first? Why does that take so long?
Because a semi-accurate progress bar is more important than getting the job done?
-
tar+scp costs twice the I/O bandwidth. Unless you have a 10Gbps network and a lot of data where using nc may make sense, tar -zcf - /blah | ssh foo@bar "tar -zxf -" is fastest.
Let me introduce you to
scp -o Compression=yes. Or configure the same in~/.ssh/config.I know, but it was single-threaded last time I looked. Definitely not as good as the above when I swap in
pigz.
-
@LaoC Compression is cheap on all modern processors, unless you use the very fanciest algorithms (the ones that look at the whole of the data before deciding to compress anything). Streaming compression algorithms like DEFLATE are able to keep up with pretty much any network or disk hardware you might have involved.
Depends on how many cores you're able to throw at it. My i7-1270P single-thread gzips (that's the same zlib algorithm as DEFLATE) /dev/zero at ~310 MB/s, /dev/random at a mere 40 MB/s. The result of
tar -cf - /homeas some somple real-world data doesn't get much above 50MB/s. UsingpigzI can get 300 MB/s, but that's still not as much as I could push through 10 Gbps uncompressed. I just tried on a 48-core server and I get about 500 MB/s before it's presumably the disks that max out while pigz burns about 20 cores. So if you have that many, compression may be worth it. But then you still may not want to use ssh with its single-threaded encryption, which is faster than compression but may be a bottleneck, too.Windows's file copy is doing something weird behind the scenes. Why does it need to make a full list of the files first? Why does that take so long?
Because a semi-accurate progress bar is more important than getting the job done?
It should be using every single CPU cycle, dammit, no time for āprogress barsā or āUI updatesā. Burn them cycles for mah compressionz!
-
tar+scp costs twice the I/O bandwidth. Unless you have a 10Gbps network and a lot of data where using nc may make sense, tar -zcf - /blah | ssh foo@bar "tar -zxf -" is fastest.
Let me introduce you to
scp -o Compression=yes. Or configure the same in~/.ssh/config.I know, but it was single-threaded last time I looked. Definitely not as good as the above when I swap in
pigz.And
tar -czf -which you mentioned in the post before mine literally pipes to gzip. Or did last time I checked.
-
tar+scp costs twice the I/O bandwidth. Unless you have a 10Gbps network and a lot of data where using nc may make sense, tar -zcf - /blah | ssh foo@bar "tar -zxf -" is fastest.
Let me introduce you to
scp -o Compression=yes. Or configure the same in~/.ssh/config.I know, but it was single-threaded last time I looked. Definitely not as good as the above when I swap in
pigz.And
tar -czf -which you mentioned in the post before mine literally pipes to gzip. Or did last time I checked.And?
-
Modern windows versions actually materialize the list, reading which source files exist, and whether any conflicting files already exist in the destination. Then if there are any conflicts it asks for confirmation. And only then it starts copying.
macOS Finder does much the same. If youāre copying many files, itās aggravatingly slow, especially if you know there wonāt be any conflicts (like copying into an empty folder on a drive that has far more space than needed). Which is why I tend to turn to the terminal for things like that.
-
Windows's file copy is doing something weird behind the scenes. Why does it need to make a full list of the files first? Why does that take so long?
Purportedly it's retrieving permissions, size including holes,access-ability, and a myriad of would-be helpful data to predict the successful-ness the operation.
Is it worth it? Demonstrably not.
-
especially if you know there wonāt be any conflicts
I wish there's was a "turn off safety checks I know what I'm doing" option.
-
@sebastian-galczynski said in WTF Bites:
scp would be just as slow,
Timing the same thing as @LaoC
$ time find . | wc -l 50012 real 0m0.279s user 0m0.027s sys 0m0.062s $ time find . | wc -l 50012 real 0m0.058s user 0m0.034s sys 0m0.044sFirst is after dropping caches, second is cached. Either would never have been enough time to take a screenshot.
Recall that that part didn't even copy any files yet, so whatever Windows was doing there would be strictly over actually transferring stuff.
Even if enumerating files for some reason takes a lot of time, one should be able to start copying as soon as the first file is discovered.
-
one should be able to start copying as soon as the first file is discovered.
Not if you want to check that everything should fit.
(screen snip not mine)
-
@sebastian-galczynski said in WTF Bites:
scp would be just as slow,
Timing the same thing as @LaoC
$ time find . | wc -l 50012 real 0m0.279s user 0m0.027s sys 0m0.062s $ time find . | wc -l 50012 real 0m0.058s user 0m0.034s sys 0m0.044sFirst is after dropping caches, second is cached. Either would never have been enough time to take a screenshot.
Recall that that part didn't even copy any files yet, so whatever Windows was doing there would be strictly over actually transferring stuff.
Even if enumerating files for some reason takes a lot of time, one should be able to start copying as soon as the first file is discovered.
Try
time find . -printf "%s\n" | wc -l. That will force it to fetch the file size on each file. Otherwise find uses an optimization which lets it avoid the stat() if it knows there are no subdirectories.
-
$ time find . -printf "%s\n" | wc -l 50012 real 0m0.452s user 0m0.026s sys 0m0.181s $ time find . -printf "%s\n" | wc -l 50012 real 0m0.096s user 0m0.022s sys 0m0.074s (drop caches again) $ time du -sh 2.6G . real 0m0.420s user 0m0.016s sys 0m0.168s $ time du -sh 2.6G . real 0m0.072s user 0m0.010s sys 0m0.062sThere are about 6k subdirectories and the rest is regular files.
Edit:
@Tsaukpaetra said in WTF Bites:Not if you want to check that everything should fit.
Fair point. If you want to check that things fit, you'd have to at least compute the total size. (Not sure if that's enough when dealing with tons of small files ... depending on how the FS handles those.)
-
@cvi Not really surprising results. And that's about all you should need to know.
Fair point. If you want to check that things fit, you'd have to at least compute the total size. (Not sure if that's enough when dealing with tons of small files ... depending on how the FS handles those.)
The only case I can think of where a simple
stat(2)doesn't give you all the information for that is with sparse files where the source and destination filesystem have different block sizes.Of course that assumes your copy program has access to all that filesystem geometry in the first place.
-
@sebastian-galczynski said in WTF Bites:
Dear Windows, I asked you to copy files, not discover them.
Any program would have to list the files
If I type this at a command prompt:
The copying begins instantaneously. There is no "discovering".
-
-
@HardwareGeek Obligatory xkcd
-
@sebastian-galczynski said in WTF Bites:
Dear Windows, I asked you to copy files, not discover them.
Windows "discovering" the files took about as long as scp took to copy them to the network share in the first place. Windows is currently copying files at a rather leisurely pace.
Note to self: next time, just use cygwin+scp on Windows.
Any program would have to list the files, unless you just dump the whole partition image. scp would be just as slow, unless you tar all these files into one, which i'd recommend. Don't gzip them though, use scp -C instead.
tarandscpwould have to discover files all the same. Although this should never take significant time for a few 10k files at least on local file systems. This is worst-case after dropping all caches:[root@c2d1gg0 ~]# time find 2>/dev/null /home | wc -l 2037066 real 0m20.103s user 0m0.638s sys 0m3.174star+scp costs twice the I/O bandwidth. Unless you have a 10Gbps network and a lot of data where using
ncmay make sense,tar -zcf - /blah | ssh foo@bar "tar -zxf -"is fastest.Not sure I understand. Can you elaborate how tar+scp is different from tar+ssh?
-
@Tsaukpaetra said in WTF Bites:
one should be able to start copying as soon as the first file is discovered.
Not if you want to check that everything should fit.
(screen snip not mine)Yeah, sure. Reminds me of these (game) installers that take forever to ācalculate available disk spaceā, while I literally sit there watching and thinking: you know, I can just open explorer and look at it. Should I tell you? Itād probably be faster if I told you the available disk space than wait for whatever the fuck youāre doing.
-
@Tsaukpaetra said in WTF Bites:
one should be able to start copying as soon as the first file is discovered.
Not if you want to check that everything should fit.
(screen snip not mine)Yeah, sure. Reminds me of these (game) installers that take forever to ācalculate available disk spaceā, while I literally sit there watching and thinking: you know, I can just open explorer and look at it. Should I tell you? Itād probably be faster if I told you the available disk space than wait for whatever the fuck youāre doing.
This reminds me of the installer for the original baldur's gate. It knew exactly how much disk space it needed. If you wanted to install all game data (so you didn't have to juggle between 6 CDs later on), it was about 2.5GB. It would then (immediately) tell you there was only 2.1GB available, even if you had more. It would offer you to ignore that and continue anyway.
-
@PleegWat good old int32 overflow.
-
@HardwareGeek Obligatory xkcd
What makes the Windows File Copy Dialog extra fucking stupid is using time as a measurement. There are too many things - most of them outside of your control - that can affect how long it will take to copy files.
The simple, sensible way of doing it would be to display the total number of bytes to be copied and the number of bytes that have been copied so far. For some reason, a company with 200,000 employees and Eleventy Gazillion Dollars can't seem to figure that out.
And speaking of Extra Fucking Stupid, there is this little gem:
Drag a file from one location to another. Windows pops up a notification that there is already a file in the destination folder with the same name and it asks you what you want to do.
If you select "Skip this file" it displays an animated progress bar.
It doesn't do anything. It doesn't copy the file. But it still displays an animated progress bar.
-
@ben_lubar said in WTF Bites:
Mac and Cheetos.
Excuse me, where's the Mac? I only see Cheetos and Cheese.
this is me .
