Slashdot Mirror

Right now. These words are being typed on an MS Natural (version 1) PS/2 keyboard directly attached to a PS/2 port on the motherboard of the computer yadda-yadda-yadda. It gives me < 2 ms delay from keypress to raised interrupt pin. I couldn't find a USB keyboard that gave reliably less than 25 ms keypress to USB controller interrupt. Don't get started on wireless crap.

From someone else's measurements report https://danluu.com/keyboard-latency/
"computers from the 70s and 80s commonly have keypress-to-screen-update latencies in the 30ms to 50ms range out of the box, whereas modern computers are often in the 100ms to 200ms range when you press a key in a terminal."
He has also provided data on "keypress and the display of a character". https://danluu.com/input-lag/
He's measuring something slightly different than what I measured, but my numbers are compatible with his.

One of my AT keyboards is sitting a foot or so to the right. It is attached to a different working computer's AT port. Unlike several motherboard's and hub's USB ports, I have never had an AT or PS/2 port fry itself when experimental hardware was plugged into it. (There is a specification for current and voltage that these three ports are required to accept without damage. Guess which ports frequently don't meet their spec because missing isolation isn't readily visible. Hint: It's the one I'm not using.) I've had exactly the same outcomes with devices' 3.5 mm audio plugs (and attendant circuits) surviving experimentation where "replacement" plugs die due to poor isolation.

Right now. These words are being typed on an MS Natural (version 1) PS/2 keyboard directly attached to a PS/2 port on the motherboard of the computer yadda-yadda-yadda. It gives me < 2 ms delay from keypress to raised interrupt pin. I couldn't find a USB keyboard that gave reliably less than 25 ms keypress to USB controller interrupt. Don't get started on wireless crap.

From someone else's measurements report https://danluu.com/keyboard-latency/
"computers from the 70s and 80s commonly have keypress-to-screen-update latencies in the 30ms to 50ms range out of the box, whereas modern computers are often in the 100ms to 200ms range when you press a key in a terminal."
He has also provided data on "keypress and the display of a character". https://danluu.com/input-lag/
He's measuring something slightly different than what I measured, but my numbers are compatible with his.

One of my AT keyboards is sitting a foot or so to the right. It is attached to a different working computer's AT port. Unlike several motherboard's and hub's USB ports, I have never had an AT or PS/2 port fry itself when experimental hardware was plugged into it. (There is a specification for current and voltage that these three ports are required to accept without damage. Guess which ports frequently don't meet their spec because missing isolation isn't readily visible. Hint: It's the one I'm not using.) I've had exactly the same outcomes with devices' 3.5 mm audio plugs (and attendant circuits) surviving experimentation where "replacement" plugs die due to poor isolation.

If you thought that your i7 is less responsive than a C64... Then you might actually be correct.
Have a look at this guy's research on latency and input lag. Granted, some of the machines he has tested on are fairly dated by now, but the general concept remains that a newer machine, while being essentially infinitely faster than a C64 or an Apple 2e, they all generally take longer to put a character on the screen once you've hit a key on the keyboard. Granted, they're also doing a lot more to put that character there, but the fact remains that overall latency has increased as computers have got faster.

https://danluu.com/input-lag/
https://danluu.com/keyboard-la...

If you thought that your i7 is less responsive than a C64... Then you might actually be correct.
Have a look at this guy's research on latency and input lag. Granted, some of the machines he has tested on are fairly dated by now, but the general concept remains that a newer machine, while being essentially infinitely faster than a C64 or an Apple 2e, they all generally take longer to put a character on the screen once you've hit a key on the keyboard. Granted, they're also doing a lot more to put that character there, but the fact remains that overall latency has increased as computers have got faster.

https://danluu.com/input-lag/
https://danluu.com/keyboard-la...

AFAICT, most web properties which would even consider using AMP in the first place have never seen a JavaScript tracking framework they didn't like. Oh, LardScript Analytics? Yes, sign me up! I realize that you can't just deliver my 2k of actual content, you need to brand and stuff with headers and footers and links to follow, but do you really need 20MB spread across 350 resources to do it? Get that down to something reasonable like 50k of dynamic stuff and a couple 100k of highly-cacheable stuff, and AMP would be pointless.

https://danluu.com/web-bloat/

Based on this article, I can believe they shipped flawed CPUs without knowing about the flaws. However, if so, it's because they deliberately stopped investing as much effort into finding the flaws in the first place.

And they certainly knew what they were doing when they scaled back their validation.

I'd like to see a court case. Wouldn't this be thrown out as an obvious violation of free speech?

Perhaps you haven't been watching too closely but this 'take your customer to court & try and destroy him' approach to doing business in the tech world has been going on since at least the '80s to my knowledge. It occurs because the US justice system has been whored out to the john packing the biggest wallet. It's not about justice, it's about money - that's the American Way.

Somebody who can take considerable credit for the 'sue 'em if they benchmark it & realise it's overpriced shit' subgenre as demonstrated by Intel in this case, is the verminous, coiffed poltroon and great helmsman (who shat himself on the Sydney/Hobart one memorable year - what a complete & total helm'): Larry Ellison.

Trying to get a prof fired for doing benchmarks? Threatening to sue security researchers reporting bugs in contradiction to Oracle's EULA? Yep, the maggot Larry.

This won't stop happening until enough people stop buying their stuff, and stop buying from people who buy their stuff.

It's happening to Oracle and it's going to be happening to Intel too. You can pass the odd cockup off as an aberration but a veritable blizzard of them?

It's not like they're the only game in town, let alone the best game.

Intel shareholders must be wondering why their shiney new CEO resembles the old one in every respect: a completely clueless horse's cock.

Time to fire the board, folks, or your business is toast. Actually, I think a rebrand might be in order.

Give the name: IG Farben a go perhaps? Memories are short and they had a better reputation back then than you have now with "Intel".

I was one of those who called "no way" at first, but just yesterday I found this quote from an Intel engineer. It was originally posted in a reddit thread but has since been deleted - but not before being confirmed by other former engineers at Intel.

As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.

Why?

Let me set the scene: It's late in 2013. Intel is frantic about losing the mobile CPU wars to ARM. Meetings with all the validation groups. Head honcho in charge of Validation says something to the effect of: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times... we can't live forever in the shadow of the early 90's FDIV bug, we need to move on. Our competition is moving much faster than we are" - I'm paraphrasing. Many of the engineers in the room could remember the FDIV bug and the ensuing problems caused for Intel 20 years prior. Many of us were aghast that someone highly placed would suggest we needed to cut corners in validation - that wasn't explicitly said, of course, but that was the implicit message. That meeting there in late 2013 signalled a sea change at Intel to many of us who were there. And it didn't seem like it was going to be a good kind of sea change. Some of us chose to get out while the getting was good. As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.

As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently. Why? Let me set the scene: It’s late in 2013. Intel is frantic about losing the mobile CPU wars to ARM. Meetings with all the validation groups. Head honcho in charge of Validation says something to the effect of: “We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our competition is moving much faster than we are” - I’m paraphrasing. Many of the engineers in the room could remember the FDIV bug and the ensuing problems caused for Intel 20 years prior. Many of us were aghast that someone highly placed would suggest we needed to cut corners in validation - that wasn’t explicitly said, of course, but that was the implicit message. That meeting there in late 2013 signaled a sea change at Intel to many of us who were there. And it didn’t seem like it was going to be a good kind of sea change. Some of us chose to get out while the getting was good. As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.

It's basically the same fuck-up as in the software industry: Profits and "time-to-market" prioritized over security.

provide 6502 performance from an i7

Good, it's a step in the direction of improving latency. Next, replace the rest of the computer with an Apple //E and we'll have something responsive. Article measuring latency of various computers that finds the Apple //E to have the least latency in displaying a character, https://danluu.com/input-lag/

Bah, they didn't test an Amiga. Subjectively, the most responsive computer I ever used.

provide 6502 performance from an i7

Good, it's a step in the direction of improving latency. Next, replace the rest of the computer with an Apple //E and we'll have something responsive.
Article measuring latency of various computers that finds the Apple //E to have the least latency in displaying a character, https://danluu.com/input-lag/

Most people don't change phone every year despite companies telling them they should.

See : https://danluu.com/android-upd...
This is an article telling how many outdated Android devices there are. Normally, this is a bad thing, and it is the take of the article. However, it shows that a lot of people don't buy into that planned obsolescence thing and that phones last much longer than a year or so. If you look at the end of the curve, you'll see that 30% of devices are at least 3 year outdated. Which mean they are probably at least 4 years old and still working.

For Apple, their marketing strategy is to treat the previous generation as it doesn't exist. They remove them from stores, from their websites, they only briefly mention them by telling how the new devices are better but even that is kept to a minimum. But that's a trick, the older devices still exist, and there is a thriving second hand market they want you to turn your attention away from.

> Because Linux normally lets you use your choice of file system on top of your choice of volume manager,

The problem is: btrfs, exfat, ext3, ext4, fat, jfs, reisderfs, and xfs ALL SUCK -- they all propagated write errors

FS / read / write /silent
btrfs.. | prop prop prop
exfat.. | prop prop ignore
ext3... | prop prop ignore
ext4... | prop prop ignore
fat.... | prop prop ignore
jfs.... | prop ignore ignore
reiserfs | prop prop ignore
xfs.... | prop prop ignore

Here's a blog post from Dan Luu on the topic of "Why's that company so big? I could do that in a weekend". Turns out there's a lot to do in a lot of places...

Can someone explain to me why this takes billions of dollars and a building full of PhDs???

Makes me think of this post from Dan Luu...

"I’m amazed at how quickly it’s possible to destroy user trust, and how much easier it is to destroy a brand than to create one. In that vein, it’s funny to see Slashdot (which is owned by the same company as SourceForge) also attempting to destroy their own brand" ref

"I’m amazed at how quickly it’s possible to destroy user trust, and how much easier it is to destroy a brand than to create one. In that vein, it’s funny to see Slashdot (which is owned by the same company as SourceForge) also attempting to destroy their own brand" ref

Apparently one of the justifications for spending space on such a ridiculously specialized task, is that in the rare event that it's being used, some of the other stuff (e.g. the general-purpose parts) might have a brief opportunity to cool off a bit. Your bigger cache wouldn't have that advantage, because you'd be using it so often.

Some say often-dark silicon will be a growing trend.

http://danluu.com/slashdot-sou...

http://danluu.com/slashdot-sou...

SF claims the project was abandoned in 2013.

To quote another user from Ars:

"the files page has the folder GIMP + GTK+ (stable release) with a last modified time of 2014-11-18. In that, GIMP 2.8.14 is the latest with the 2014-11-18 modification date. The previous file, GIMP 2.8.10 has a modification date of 2014-05-29. (This is just shy of 6 months.) The one before that, GIMP 2.8.8 is also last modified 2014-05-29, and the one before that is GIMP 2.8.6 last modified on 2013-06-24. (This one is just shy of 11 months back.)

So the project was abandoned, but a year later, it's still updating files. And it had three releases in the year after it was supposedly abandoned. The last release was just a few days over 6 months ago, and the project has a history of up to 11 months between releases. How does that qualify as "abandoned"?

No, this is a bullshit excuse Sourceforge was hoping no one would delve into the details to call their bullshit on. There is no other way to put it than they flat-out lied about the abandonment."

Oh, and to boot - According to the gimp-win developer, they locked him out of his account.

That's right, SourceForge STOLE THE ACCOUNT using an account called SF-editor1 in order to wrap one of the most popular FOSS projects with a malware installer.

So here's what we do, guys. I've got a really good attorney. Same one that helped me kick EA's ass back in the Spore lawsuit days.

We band together, we find every person that has had this malware pushed on them, and we sue the ever-living shit out of SourceForge in a class-action suit where accepting a settlement is NOT AN OPTION. Knowingly distributing malware, using misleading language to get the malware to install, and the damage the malware does to the user's computer are all entirely actionable in court and we need to band together to put a legal end to this crap once and for all. We now have the evidence in the testimony of the former account holder, we have copies of the malware, we have copies of the installer, we have screencapped evidence of the lies SourceForge has posted. SourceForge is DEAD IN COURT.

Look up Mark Punzalan Law. Let him know Alex from the Spore/EA case sent you.

If you want, I can come forth as class representative again. I will be more than happy to be the headman ripping these people apart in court.