But let us please note that the choice of α (low pass filter gain constant) in the original round trip estimator of the TCP congestion avoidance algorithm by Van Jacobson is not arbitrary.
735 karma · joined December 22, 2011
dig +trace messenger.com
dig @a.ns.facebook.com messenger.com
;; connection timed out; no servers could be reached
ping a.ns.facebook.com
3 packets transmitted, 0 packets received, 100.0% packet loss
But a very small minority that doesn't have morals, is causing the illusion that it's most people that don't have them.
* There is a huge subset of motorized vehicles that are spending a considerable percentage of their daily time on the road. Thinking about taxis, buses, trucks, etc.
* A large percentage of private cars are parked on the streets.
Those two observations alone make the case for electric vehicles slightly problematic.
Of course, a private individual with a garage can get an electric vehicle and use it almost like an ICE one, with a large environmental but also budgetary gain.
But for these other classes of vehicles, hydrogen could provide a better alternative.
Apologies if I'm missing something, but I cannot think what other zero emission technology could give the solution at this point, for these types of vehicle usage.
So it completely boggles the mind that, during the last decade, we are witnessing an unbelievable onslaught to any sane UI convention that people have come to expect. At the top of my head:
- No accessibility at all, even though there are extensive sets of standards fully implemented by the UI toolkit. - No scrollbars at all. Even worse, scrollbars that don't behave quite right.
- Ugly styling that doesn't follow even the most basic modicum of guidelines crystalized around the 80s.
- Text boxes and other widgets that have hidden weird behaviours, or are generally ridiculously slow.
- UI widgets that are badly sized and don't correctly follow the regular zoom controls.
- Windows without a title bar that can be moved only by dragging them from a specific small and narrow area.
- Trivial apps for which the browser has to download megabytes of js and raise the CPU to a point that the fans need to start spinning.
- Cryptic icons that don't have any semantic connection with what they are supposed to accomplish.
- My favourite, UI widgets that cannot stay where they where originally placed, resulting in failures to click them as they keep moving/reflowing under the button. Because the toolkit decided to reflow while the user was already allowed to interact with it.
- Phone button menus that have an unknown size below the bottom of the screen and there is no visible clue how many icons below the bottom are not visible.
We are possibly very near hitting rock bottom in terms of UI in 2021, which (oddly enough) means that there is bound to be a renaissance of some sort as regards those things. After the middle ages many turned to the classical antiquity for inspiration. Drooling over the skeuomorphic UIs of the original iPhone and the pseudo-3d toolkits of the 1990s...
Intel mac, usb-c sound to an external 4k monitor used to work flawlessly in Mojave. Big Sur, stopped working.
But there's a bigger issue here. The comments the OP received, are heavily worded to the point that they explicitly state that the article made them angry.
Regardless of whether containers are suitable or not for task X or Y, it is very difficult to have a normal conversation, if one's comments can actually make people angry.
Also, in addition to SAS, a fibre channel card would also fit the bill, albeit probably a trifle more expensive. But if you go for low speeds (e.g. 8Gbps), those cards can be less than 100$.
All the comments suggesting that this somehow shouldn't be and that people should move away from PDL, are depressing in the way that, in a split second, years of effort and thousands lines of code that are probably doing good work are dismissed just like that.
If a bank is still using Cobol, it is interesting and a testament to how a Cobol programmer can still make a good living on it. But if a scientist is using Perl to carry out calculations, this is somehow bad?
Now you have to carefully see what the packaging says, which can range from inadvertently unclear to downright misleading. And to add to that, you don't know what to look for in the first place if you don't have prior experience with thunderbolt/usb-c. Example, I didn't know that a cable must explicitly mention DP in order to connect to an external monitor. Because it was the first time I had an external monitor that can use usb-c.
Not really complaining, usb-c is very very nice. Just pointing the minor annoyance of learning its warts.
Having said that, this caught my eye:
> There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details.
Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using both Ansible and Puppet in my previous job, and we always found it mildly annoying that upgrading a system (Linux, FreeBSD) would, in addition to the other "usual" dangers, bring along the danger of the new version not having a package for the "old" version of Puppet or Ansible that we were using. Which would force us to divert attention to the automation tool's problems instead of using the automation tool to solve problems.
I do understand that nothing can stand still and everything must evolve and change, but at some point this acquires the flavour of changes for the sake of changes. Especially when regressions happen and things that were working perfectly are now breaking, it is not exactly pleasant to have to devote time to them.
It's not exactly clear how can Perl programs or shell scripts or Makefiles from 20 years ago play perfectly fine unchanged, but the syntax of a manifest or playbook that does a couple of simple operations cannot remain stable. It's not like those tools were created yesterday, in which case it would be reasonable to expect changes in their first years.
I dare say this also adds credit to the approach of FreeBSD, where the base system itself includes some basic libraries such as openssl, etc. Updating the system patches the libraries uniformly, so any ports using them are automatically patched. And there is no problem with security patches breaking compatibility, because the version of libraries in base remains mostly stable for a particular version of FreeBSD and security patches are backported as necessary. Which is of course what happens in popular long-term support Linux distributions too, albeit at the package level.
It is also possible to have ports that use a different version of a library too, though that often requires building custom packages locally or via a centralized Poudriere builder.
Please consider that today, in 2021, IPv4 is still the only thing supported in many venues. It took almost 20 years for IPv6 to become universally supported by Operating Systems, ISPs, providers, etc, but still you have to have IPv4.
And I dare say IPv6 was much much more critical to have than QUIC.
But having said all that, what is there to allow in QUIC? Isn't it just using UDP?
If everything that uses X11 today can be used on top of XWayland without any modification and without performance loss, this means that a lot of pressure stemming from the need to switch to speaking Wayland instead of X11 is lifted in a certain sense.
Or am I missing something?
Your huddled masses yearning to breathe free,
The wretched refuse of your teeming shore.
Send these, the homeless, tempest-tost to me,
I lift my lamp beside the golden door!
With all due respect to your (otherwise perfectly valid) argument, "there's more than one way to do it" was never a real problem with people using Perl. I dare say it's fully possible to write difficult-to-read code in any language.
Perl was expressly never interested in erecting glass walls and force people this or that way. Not saying that this is good or bad. But it's the way the people who are making Perl want it.
It's possible that there are deep assumptions in the Linux code that some fundamental software or hardware memory handling capabilities are present.
To this day, I have never seen anything that can even remotely approach the ability of Perl to prototype something out of thin air. Usually there is a gap between script-like tools (like sh, sed, awk, grep, jq, curl, etc) with which you can quickly put together stuff and a "real" language which usually needs scaffolding and preparation. Perl can do both, you can write excellent one-liners and you can also write complex software with libraries and frameworks and dependencies and tests.