Browsing the web today feels similar to 25 years ago. Even all this wobbling that my link above demonstrates already existed back then (in a way), but it was caused by images loading so slowly. Then, for a brief moment, some browser (I don’t remember which one) had this brilliant feature of trying to keep the current scrolling position *stable* while the page was still loading. That was great. 😃 This feature then got lost again, probably because it’s too hard to do with JavaScript changing the DOM all the time. So now we’re back to the way it was before.
Corporations should give devs the slowest and oldest machines that they have. 😏 Not only would this be more sustainable, it would also force them to optimize better.
Browsing the web today feels similar to 25 years ago. Even all this wobbling that my link above demonstrates already existed back then (in a way), but it was caused by images loading so slowly. Then, for a brief moment, some browser (I don’t remember which one) had this brilliant feature of trying to keep the current scrolling position *stable* while the page was still loading. That was great. 😃 This feature then got lost again, probably because it’s too hard to do with JavaScript changing the DOM all the time. So now we’re back to the way it was before.
Corporations should give devs the slowest and oldest machines that they have. 😏 Not only would this be more sustainable, it would also force them to optimize better.
Browsing the web today feels similar to 25 years ago. Even all this wobbling that my link above demonstrates already existed back then (in a way), but it was caused by images loading so slowly. Then, for a brief moment, some browser (I don’t remember which one) had this brilliant feature of trying to keep the current scrolling position *stable* while the page was still loading. That was great. 😃 This feature then got lost again, probably because it’s too hard to do with JavaScript changing the DOM all the time. So now we’re back to the way it was before.
Corporations should give devs the slowest and oldest machines that they have. 😏 Not only would this be more sustainable, it would also force them to optimize better.
Browsing the web today feels similar to 25 years ago. Even all this wobbling that my link above demonstrates already existed back then (in a way), but it was caused by images loading so slowly. Then, for a brief moment, some browser (I don’t remember which one) had this brilliant feature of trying to keep the current scrolling position *stable* while the page was still loading. That was great. 😃 This feature then got lost again, probably because it’s too hard to do with JavaScript changing the DOM all the time. So now we’re back to the way it was before.
Corporations should give devs the slowest and oldest machines that they have. 😏 Not only would this be more sustainable, it would also force them to optimize better.
The bullet point 8.6 continues right away (I forgot the ellipsis in my initial quote, excuse me):
> \n Customer agrees that it is Customer’s responsibility to ensure safe use of an Offering and the CrowdStrike Tools in such applications and installations. CROWDSTRIKE DOES NOT WARRANT ANY THIRD PARTY PRODUCTS OR SERVICES.
And in the one before that:
> 8.5 No Guarantee. CUSTOMER ACKNOWLEDGES, UNDERSTANDS, AND AGREES THAT CROWDSTRIKE DOES NOT GUARANTEE OR WARRANT THAT IT WILL FIND, LOCATE, OR DISCOVER ALL OF CUSTOMER’S OR ITS AFFILIATES’ SYSTEM THREATS, VULNERABILITIES, MALWARE, AND MALICIOUS SOFTWARE, AND CUSTOMER AND ITS AFFILIATES WILL NOT HOLD CROWDSTRIKE RESPONSIBLE THEREFOR.
In other words: "Just give us your money and hope for the best. It might work. Maybe." Nope, of course it doesn't.
The bullet point 8.6 continues right away (I forgot the ellipsis in my initial quote, excuse me):
> […] Customer agrees that it is Customer’s responsibility to ensure safe use of an Offering and the CrowdStrike Tools in such applications and installations. CROWDSTRIKE DOES NOT WARRANT ANY THIRD PARTY PRODUCTS OR SERVICES.
And in the one before that:
> 8.5 No Guarantee. CUSTOMER ACKNOWLEDGES, UNDERSTANDS, AND AGREES THAT CROWDSTRIKE DOES NOT GUARANTEE OR WARRANT THAT IT WILL FIND, LOCATE, OR DISCOVER ALL OF CUSTOMER’S OR ITS AFFILIATES’ SYSTEM THREATS, VULNERABILITIES, MALWARE, AND MALICIOUS SOFTWARE, AND CUSTOMER AND ITS AFFILIATES WILL NOT HOLD CROWDSTRIKE RESPONSIBLE THEREFOR.
In other words: "Just give us your money and hope for the best. It might work. Maybe." Nope, of course it doesn't.
https://movq.de/v/112a927861/hiccupfx/
😂😭
https://movq.de/v/112a927861/hiccupfx/
😂😭
https://movq.de/v/112a927861/hiccupfx/
😂😭
https://movq.de/v/112a927861/hiccupfx/
😂😭
As we all know, writing a Wayland compositor from scratch is next to impossible. Luckily, there’s the wlroots project which aims to build a base library for this task. Basically every compositor except for GNOME and KDE uses it. (This is good! The less fragmentation, the better.)
wlroots is still very volatile, lots of changes with every release. Downstream users (i.e., the projects that write the actual compositor) have to constantly “chase” changes in wlroots. dwl, my favorite compositor at the moment, has recently switched their
main branch to target the wlroots *git* version instead of the latest release. My understanding is that they *have* to do this in order to keep up with wlroots (maybe I’m wrong).Everything is volatile and a moving target.
Why does any of this matter for me? Because I have to eventually fork dwl or at least keep a patch set, and I don’t have the stamina to constantly fiddle with this stuff. I’m running my own X11 window manager, it’s highly specialized, and using just “some Wayland compositor out there” is a *huge* step backward that I’m not willing to take. I tried, it’s just painful and annoying with *zero* benefits.
So … it was fun experimenting with Wayland a bit, but I’m now back to waiting for things to settle down considerably.
As we all know, writing a Wayland compositor from scratch is next to impossible. Luckily, there’s the wlroots project which aims to build a base library for this task. Basically every compositor except for GNOME and KDE uses it. (This is good! The less fragmentation, the better.)
wlroots is still very volatile, lots of changes with every release. Downstream users (i.e., the projects that write the actual compositor) have to constantly “chase” changes in wlroots. dwl, my favorite compositor at the moment, has recently switched their
main branch to target the wlroots *git* version instead of the latest release. My understanding is that they *have* to do this in order to keep up with wlroots (maybe I’m wrong).Everything is volatile and a moving target.
Why does any of this matter for me? Because I have to eventually fork dwl or at least keep a patch set, and I don’t have the stamina to constantly fiddle with this stuff. I’m running my own X11 window manager, it’s highly specialized, and using just “some Wayland compositor out there” is a *huge* step backward that I’m not willing to take. I tried, it’s just painful and annoying with *zero* benefits.
So … it was fun experimenting with Wayland a bit, but I’m now back to waiting for things to settle down considerably.
As we all know, writing a Wayland compositor from scratch is next to impossible. Luckily, there’s the wlroots project which aims to build a base library for this task. Basically every compositor except for GNOME and KDE uses it. (This is good! The less fragmentation, the better.)
wlroots is still very volatile, lots of changes with every release. Downstream users (i.e., the projects that write the actual compositor) have to constantly “chase” changes in wlroots. dwl, my favorite compositor at the moment, has recently switched their
main branch to target the wlroots *git* version instead of the latest release. My understanding is that they *have* to do this in order to keep up with wlroots (maybe I’m wrong).Everything is volatile and a moving target.
Why does any of this matter for me? Because I have to eventually fork dwl or at least keep a patch set, and I don’t have the stamina to constantly fiddle with this stuff. I’m running my own X11 window manager, it’s highly specialized, and using just “some Wayland compositor out there” is a *huge* step backward that I’m not willing to take. I tried, it’s just painful and annoying with *zero* benefits.
So … it was fun experimenting with Wayland a bit, but I’m now back to waiting for things to settle down considerably.
As we all know, writing a Wayland compositor from scratch is next to impossible. Luckily, there’s the wlroots project which aims to build a base library for this task. Basically every compositor except for GNOME and KDE uses it. (This is good! The less fragmentation, the better.)
wlroots is still very volatile, lots of changes with every release. Downstream users (i.e., the projects that write the actual compositor) have to constantly “chase” changes in wlroots. dwl, my favorite compositor at the moment, has recently switched their
main branch to target the wlroots *git* version instead of the latest release. My understanding is that they *have* to do this in order to keep up with wlroots (maybe I’m wrong).Everything is volatile and a moving target.
Why does any of this matter for me? Because I have to eventually fork dwl or at least keep a patch set, and I don’t have the stamina to constantly fiddle with this stuff. I’m running my own X11 window manager, it’s highly specialized, and using just “some Wayland compositor out there” is a *huge* step backward that I’m not willing to take. I tried, it’s just painful and annoying with *zero* benefits.
So … it was fun experimenting with Wayland a bit, but I’m now back to waiting for things to settle down considerably.
this was a fun one. it was suppose to rain and thunder this morning so i was pretty psyched to get out there. but the storm never came. either way it was a good run.
#running
this was a fun one. it was suppose to rain and thunder this morning so i was pretty psyched to get out there. but the storm never came. either way it was a good run.
#running
this was a fun one. it was suppose to rain and thunder this morning so i was pretty psyched to get out there. but the storm never came. either way it was a good run.
#running
That's some good sleuth thing that @lyse 🙇♂️
That's some good sleuth thing that @lyse 🙇♂️
Sunset
> 8.6 \n THE OFFERINGS AND CROWDSTRIKE TOOLS ARE NOT FAULT-TOLERANT AND ARE NOT DESIGNED OR INTENDED FOR USE IN ANY HAZARDOUS ENVIRONMENT REQUIRING FAIL-SAFE PERFORMANCE OR OPERATION. NEITHER THE OFFERINGS NOR CROWDSTRIKE TOOLS ARE FOR USE IN THE OPERATION OF AIRCRAFT NAVIGATION, NUCLEAR FACILITIES, COMMUNICATION SYSTEMS, WEAPONS SYSTEMS, DIRECT OR INDIRECT LIFE-SUPPORT SYSTEMS, AIR TRAFFIC CONTROL, OR ANY APPLICATION OR INSTALLATION WHERE FAILURE COULD RESULT IN DEATH, SEVERE PHYSICAL INJURY, OR PROPERTY DAMAGE.
That's why all airports remained operational. Oh wait…
> 8.6 […] THE OFFERINGS AND CROWDSTRIKE TOOLS ARE NOT FAULT-TOLERANT AND ARE NOT DESIGNED OR INTENDED FOR USE IN ANY HAZARDOUS ENVIRONMENT REQUIRING FAIL-SAFE PERFORMANCE OR OPERATION. NEITHER THE OFFERINGS NOR CROWDSTRIKE TOOLS ARE FOR USE IN THE OPERATION OF AIRCRAFT NAVIGATION, NUCLEAR FACILITIES, COMMUNICATION SYSTEMS, WEAPONS SYSTEMS, DIRECT OR INDIRECT LIFE-SUPPORT SYSTEMS, AIR TRAFFIC CONTROL, OR ANY APPLICATION OR INSTALLATION WHERE FAILURE COULD RESULT IN DEATH, SEVERE PHYSICAL INJURY, OR PROPERTY DAMAGE.
That's why all airports remained operational. Oh wait…