Linux mythbuster fail
-
Dunno about that. In my experience, running MyDefrag against a Windows 7 installation (NTFS) that's been left to its own devices for a year or so will reliably make it boot about 30% faster and make noticeable improvements to application launch speed as well.
Did you stopwatch it, or are you going purely by placebo effect?
-
Stopwatch. 33 seconds down to 25 (measured from the point where the BIOS hands over to the boot loader).
-
Wow, 25 is your good time on Windows 7? What's the RPM of your HD, 4?
But ok, fair enough. If you actually measured instead of placebo, I accept your bullshit as truth. Even though 25 still sucks.
-
And defrag will hardly be worthy the life reduction for an ssd
I'm inclined to think I'll never see the eol of a ssd drive. I've had three of the fucking things die on me so far. Well within warranty luckily enough. I think I'll either end up replacing the current ones or they'll die. I've only ever had one mechnical drive die on me. The rest I've upgraded to bigger. All those extra bits made them hard to carry though =(
-
Wow, 25 is your good time on Windows 7? What's the RPM of your HD, 4?
FYI: before SSDs hit the market, 25 seconds on a year-old W7 install was pretty good. Of course, we're speaking of cold boot (not resuming after sleep/deep sleep/hibernate), and not just showing the desktop but running all the startup programs too.
-
I've had three of the fucking things die on me so far.
That is the standard EOL behavior for an SSD. Some of the Intel ones lock to a read-only mode for one or two boots, but after that and for all the other ones, once the spares pool is depleted the drive intentionally bricks.
-
The claim is "Linux can't get malware".
Is that a Linux install? Yes.
Are those files malware? Yes.
Are those files in the Linux install? Yes.
The only possible deduction from this is that that Linux install has somehow acquired malware, which contradicts the thesis, meaning the thesis is wrong and must be discarded. I don't see how you are having difficulty with this, unless your love of Linux has blinded you to basic logic (admittedly, a prerequisite to loving Linux).
That's so completely absurd. You're completely insane. That doesn't even make any sense!
[WARN]09-20-2015 2333z WebResponse/WARN: Sarcasm level -34767, possible overrun. [INFO]09-20-2015 2333z WebResponse/INFO: Sarcasm level below set level, responding seriously. [INFO]09-20-2015 2333z WebResponse/INFO: Composing response [INFO]09-20-2015 2333z WebResponse/INFO: Response complete, posting
-
I'm inclined to think I'll never see the eol of a ssd drive. I've had three of the fucking things die on me so far.
What models?
-
Here's my entire filesystem:
/dev/sda1: 614735/9576448 files (0.2% non-contiguous), 11360897/38284800 blocks
-
http://www.amazon.co.uk/gp/product/B00E3W19MO
Two of these and a corsair one who's model I can't find.
-
You made two errors in a single word, and neither is @accalia.
-
Mistress @Gaska, You have summoned me, how may i annoy you?
/me bows deeply from within the pentagram she appeared inside of.
-
You can misspell my name if you want, though I see you already did it.
-
Here's my entire filesystem:
/dev/sda1: 614735/9576448 files (0.2% non-contiguous), 11360897/38284800 blocks ```</blockquote> Here's my entire filesystem: {DISCOURSE UPLOADING 7,573,556 bytes OF 279,492,443,872 BYTES COMPLETE}
-
Here's my entire filesystem:
Just this. Over and over.
-
I didn't know the French came up with a file system.
-
Is it possible to be racist against someone holding a white flag?
-
I bet it's perfect to spell out "Get off my lawn!"
-
1. Don't optimize.2. (Experts only) Don't optimize yet.
- Profile before and after attempting to optimize.
-
What is this 'profile' of which you speak?
-
Profile before and after attempting to optimize.
When C compilers were a new thing for embedded dev I benchmarked my lovely, hand-optimised, assembler against the rubbish the fancy new compiler was emitting. It was significantly faster and, generally, the same size (RAM and ROM) or smaller for equivalent code. That was an eye-opener.
I still used to like writing in assembly, not knowing exactly how many cycles things take take means you have to use a power-hungry timer module rather than just tuning the number of instructions in your code paths for timing purposes
-
It was significantly faster
Which? Your hand-optimized assembler or the rubbish from the compiler?
-
Which? Your hand-optimized assembler or the rubbish from the compiler?
Sorry, that was unclearly written. The compiler's code was faster. Not so rubbish after all.
The procedural abstraction was the main thing that made it look messy to my eyes I think.
-
I got a short term but quite lucrative gig once as a HPC, after an embedded project got stalled due to a project leader's several-years-premature belief that what he'd learned about the state of the art in global optimization as a CS student meant that the third-rate embedded C compiler he'd picked was equal to any task.
Turned out that a certain time-critical interrupt service routine for that particular 68000-based board worked much better if not surrounded by a bunch of compiler-generated save-everything/switch-stacks/restore-everything boilerplate. Under full interrupt load, my carefully minimalist assembly language replacement ended up consuming about 60% of the available CPU cycles; the old C code never even got as far as completing all its register saves before the device it was supposed to be servicing had overrun.
But that was in a time of far simpler CPUs. Proper on-chip caches and deep pipelines were a complete game changer for compiled code, especially after compiler writers started generally applying the lessons learned from dealing with architectures like MIPS that rely on the compiler to work out an optimal ordering for memory and register accesses. The rules for that stuff are much easier for a compiler back end to keep track of than for an assembly coder to, and they almost completely dominate the performance results.
-
What is this 'profile' of which you speak?
If you click your avatar in the top right, it's on the top line of the dropdown that opens.
-
-
When C compilers were a new thing for embedded dev I benchmarked my lovely, hand-optimised, assembler against the rubbish the fancy new compiler was emitting. It was significantly faster and, generally, the same size (RAM and ROM) or smaller for equivalent code. That was an eye-opener.
Twenty years ago.not knowing exactly how many cycles things take take means you have to use a power-hungry timer module rather than just tuning the number of instructions in your code paths for timing purposes
Too bad you cannot do it now with assembly either!
-
It's a verb my coworkers are not familiar with.
-
I hope they don't try to blindly optimize their code.
-
What do you think?
-
I think they do, and that makes me a sad panda.
-
So they all have this posted next to their desks?
-
Pretty much
-
I wrote a complete syntax parser for a made-up interpreted language to run on 8051 (8951 really) in assembly, it also had code to handle EEPROM, i2s protocol for flash, communicated with a simulated serial port on top of LPT (to download code), a PWM controller for 3 motors, ... I remember the C compiler would eat the entire space if I wanted to just do a
printf.
But that was 15 years ago and the compiler was shitty, and the micro-controller was ancient (same as 68000). Any decent compiler today will beat any hand-optimized assembly, even if you can get your head straight on how to pipeline instructions to avoid branch miss prediction.
-
If I were working on an 8051 project today (and yes, there are still some really cheap microcontrollers around with that core) I'd still be using assembly. The major technical risk with that machine is always going to be running out of resources, and it has specialist bitwise instructions and an odd memory architecture that don't fit particularly comfortably into the C abstraction model; it was clearly never designed to be a HLL target, and assembler is the path of least resistance for just about any job you'd consider it for. For people unfamiliar with 8048/8051: if you're doing anything as complicated as printf() on one of these cores, you're
.Same mostly applies to MCUs with a 6805, 6502 or PIC core. Might consider FORTH for those, but choosing any "normal" compiler would probably require designing in at least double the storage.
I think Atmel's AVR family was the first MCU architecture clearly designed primarily as a compiler target, and I think I could probably still wring a few percentage points of performance out of the odd inner loop on that architecture by hand. Anything more complex than that: yes, let the compiler deal with it, because it almost certainly will do a better job.
-
If I were working on an 8051 project today (and yes, there are still some really cheap microcontrollers around with that core) I'd still be using assembly.
I am sure you are
. I fairly recently used a chip with 8051 core, it was some TI SOC for BLE. We paid for some ridiculously expensive compiler called IAR, and printfworks fine (even though I would avoid it and useputcbecauseprintfin embedded system is always ). Compilers nowadays are ridiculously smart, they will see those %d, ... and do the right thing
perhaps by using a non-standard printf.
I used Keil 15 years ago with that 8051 micro controller and the code did not even fit! I specifically rememberprintfbut I am sure C basically was useless for anything meaningful, let alone a language parser.
-
Wow. I did watch Windows defrag like your next addict. That was in 1998. Talking about defragmentation in 2015? If he wanted to ridicule the claims he could have pointed out that there is no advantage because no modern system needs defragmentation. But no, he took that old claim seriously. And he managed to copy Windows malware into his Linux installation
But the part where his incompetence really shines is where he disputes the claim that Linux installations can boot on other systems.
Most modern Linux distributions use a Universial Unified Identifier to mate the fstab and harddrive to the system. It's a security feature.You know it - it mates with the hardware .., so it's done for security reasons and it's also done so it can log this stuff preemptively so it can boot faster. So there is a couple reasons why this is done. (Matthew Moore)
He decided to forgo reading about Persistent block device naming to come up with his own ideas why UUID are used
I just feel smug and superior now in every way. He helped me achieve what Linux is supposed to convey but often underdelivers! Would watch again.
-
The 6809 with its dual hardware stacks and powerful autoindex registers is almost ridiculously suitable for running Forth on. Now, as it happens, the Ensoniq Mirage - a sampling synthesizer from the mid-80s, that boots its OS from floppy - has a 6809 in. So, this happened:
