I realize you are tongue in cheek, but I hope people respect the logical limits of this sort of thing.
Years ago, there were some development tools coming out of the Ruby world – SASS for sure, and Vagrant if I remember correctly – whose standard method of installation was via a Ruby gem. Ruby on Rails was popular, and I am sure that for the initial users this had almost zero friction. But the tools began to be adopted by non-Ruby-devs, and it was frustrating. Many Ruby libraries had hardcoded file paths that didn’t jive with your distro’s conventions, and they assumed newer versions of Ruby than existed in your package repos. Since then I have seen the same issue crop up with PHP and server-side JavaScript software.
It’s less of a pain today because you can spin up a container or VM and install a whole language ecosystem there, letting it clobber whatever it wants to clobber. But it’s still nicer when everything respects the OS’s local conventions.
Could you explain your reasoning? I don’t see any moral difference between deliberately limiting compatibility from the peripheral side and doing so from the “computer” side (i.e., iPhone, iPad, Macintosh). One type of device may produce more inadvertent incompatibilities than the other, but that’s different.
Besides, I think this will create surprise and confusion for less technical users. In my experience, many will blame the incompatibility on whichever device is new, without understanding who is gating out whom. And even for technical users, consider CarPlay and Android Auto: From the phone’s perspective, the car is a peripheral, and that makes sense; but lots of people will still consider the car the “core device.”
Beside being a neat font in its own right, Iosevka allows for custom builds with different settings, selection from a bunch glyph variants, and custom ligature choices. It's pretty incredible.
The first few times you use it, XSLT is insane. But once something clicks, you figure out the kinds of things it’s good for.
I am not really a functional programming guy. But XSLT is a really cool application of functional programming for data munging, and I wouldn’t have believed it if I hadn’t used it enough for it to click.
Right. I didn't use it much on the client side so I am not feeling this particular loss so keenly.
But server side, many years ago I built an entire CMS with pretty arbitrary markup regions that a designer could declare (divs/TDs/spans with custom attributes basically) in XSLT (Sablotron!) with the Perl binding and a customised build of HTML Tidy, wrapped up in an Apache RewriteRule.
So designers could do their thing with dreamweaver or golive, pretty arbitrarily mark up an area that they wanted to be customisable, and my CMS would show edit markers in those locations that popped up a database-backed textarea in a popup.
What started off really simple ended up using Sablotron's URL schemes to allow a main HTML file to be a master template for sub-page templates, merge in some dynamic functionality etc.
And the thing would either work or it wouldn't (if the HTML couldn't be tidied, which was easy enough to catch).
The Perl around the outside changed very rarely; the XSLT stylesheet was fast and evolved quite a lot.
XSLT's matching rules allow a 'push' style of transform that's really neat. But you can actually do that with any programming language such as Javascript.
“They convinced a bunch of developers that their definition of Open Source that was specifically crafted to protect business interests is canon.”
They adopted the existing Debian Free Software Guidelines as the Open Source Definition. The DFSG are good, actually, and represent an important community consensus outside the FSF.
They looked around and found the guidelines that most closely matched their goals. Specifically DFSG already included a clause about not restricting commercial use.
Also if you read the original DFSG the clause about field of endeavor has been interpreted by OSI differently from the intent.
It was about saying your license can’t prevent an end user of your software from using it for a specific purpose. It really says nothing about restrictions on how you can sell the software.
The problem is OSI is now the sole interpreter of the definition.
> “Free software” does not mean “noncommercial.” On the contrary, a free program must be available for commercial use, commercial development, and commercial distribution. This policy is of fundamental importance—without this, free software could not achieve its aims.
Why is that the problem? Trademarks are one of the three branches of intellectual property. The two words "open" and "source" look like generic terms, but "Open Source" has come to mean a relatively specific thing. So have Disney and Google and Coca-cola.
The DFSG and the OSD are the same text, but the OSI and the Debian project interpret it differently, and this difference is important.
Debian (and most other distributions, btw), for the most part (or entirely, I suppose), agrees with the FSF / the GNU project when deciding which license is free or non free. The OSI has a more permissive interpretation.
RMS speaks about that in a recent interview in French [1], English translation below:
> La FSF a financé Debian à son commencement. Mais rapidement, le projet, qui comptait plus de contributeurs, a voulu formuler une définition de la liberté différente, avec l’intention d’être équivalente.
> À l’époque, j’ai commis une erreur : j’aurais dû vérifier plus attentivement s’il pouvait y avoir des divergences d’interprétation entre le projet GNU et Debian. La définition me paraissait équivalente, même si elle était formulée autrement. J’ai dit : “C’est bon.” Mais en réalité, il y avait des problèmes potentiels.
> Plus tard, quand l’open source a émergé, ils ont repris la définition de Debian, je ne sais plus s'il ont changé quelques mots mais ils ont surtout changé l’interprétation. Dès lors, elle n’était plus équivalente à celle du logiciel libre. Il existe aujourd’hui des programmes considérés comme “open source” mais pas comme logiciels libres, et inversement.
> J’ai d’ailleurs expliqué ces différences dans mon essai Open Source Misses the Point.
English translation (not a native English speaker, I hope the translation is ok, especially considering that RMS is close to his words and it's probably easy to misrepresent him without noticing):
> The FSF funded Debian at its beginnings. But rapidly, the project, gaining more contributors, wanted a different phrasing for the definition of freedom, which the intent of being equivalent.
> Back then, I made a mistake: I should have checked more carefully if there could be different ways to interpret it between the GNU and the Debian projects. The definition seemed equivalent to me, even if it was phrased differently. I said: "OK". But in reality, there were potential issues.
> Later, when Open Source surfaced, they took Debian's definition, I don't know if they changed a few words but they above all changed the interpretation. Since then, it was not equivalent to the free software definition anymore. There exist open source software that's not free software, and conversely.
> By the way, I explain all this in my Open Source Misses the Point essay.
Yep, the Sybase Open Watcom Public License. The OSI considers this license open source [1], the FSF and major distros don't [2], including Fedora [3] and Debian [4].
It is notably used by the Open Watcom C compiler, which is used to compile VirtualBox's BIOS. Which is the reason why you won't find VirtualBox in most distros, including Debian.
The reason the FSF and major distros don't consider it free is that there are cases where you can't use it privately without releasing your modifications. The license doesn't pass Debian's Desert Island test [5]:
> Imagine a castaway on a desert island with a solar-powered computer. This would make it impossible to fulfill any requirement to make changes publicly available or to send patches to some particular place. This holds even if such requirements are only upon request, as the castaway might be able to receive messages but be unable to send them. To be free, software must be modifiable by this unfortunate castaway, who must also be able to legally share modifications with friends on the island.
I don't have an example of a license that the FSF / GNU project considers free and that the OSI doesn't consider open source.
> Oops... it looks like OSI smoked something especially bad this time, I'm afraid. This license looks like someone took his time to collect every single problematic clause.
The point isn't that the developer should disable text selection whenever he thinks it's unnecessary, which would indeed be silly. It's that sometimes the user interface rules for navigating selectable text conflict or interfere with the user interface rules for navigating, say, a set of tab panes. In that situation, making the tab titles selectable will cause grief.
I agree with your address example. That is user data, and it should be selectable.
I don't think we disagree, too much. tab panes matches the "button" example.
However, I am sympathetic to those arguing translation. Sometimes I'll visit Japanese or Chinese websites. With some frequency, even if most of the site has an English edition, I'll find some UI element not translated, including buttons and the like... OK I think it was the commenter that I responded to, in a different reply said... just Google it if it's a single word. Great! But I don't even know where to begin to get the right characters from my old fashioned US keyboard. So now I have to Google for how to use my keyboard to get the characters I want, which also may need pre-requisite knowledge of the language I'm trying to translate (radicals and all that jazz)... that's a heavier lift than may be anticipated and where a simple copy/paste into an appropriate translator would make things much, much easier.
I would suggest this: make everything buttons, links, tabs, etc. selectable and copyable unless there is a real explicit and compelling reason to do otherwise. Now to be fair, I'm old enough to have been "online" in some fashion or another since before general public internet access availability was a thing... so my expectations for butter-like user experiences are low and my desire to do any damn thing I want high... but even today, there are probably still more websites which don't stop you from copying anything than there are searching for that polished experience where only the right things can be selected. The discontinuity and the deviation from the expectation that I can copy anything I also find as something which diminishes the user experience, even if occasionally I'm annoyed by over selecting things.
I agree. The closer to a traditional desktop U.I. you get, the jankier selecting clickable text becomes. For a simple web form, leaving labels selectable is no big deal and probably a win. But for something trying to behave like a tabbed dialog box, it breaks navigation left and right.
Which motherboards enable PBO out of the box? That’s crazy! I know that motherboard manufacturers set some sketchy default turbo durations for Intel CPUs back when Intel was cagey about the spec and let them get away with it, but I thought that AMD was stricter about such things.
It sounds like their lawyers have done the appropriate counter-challenge with YouTube, so the video will go back up unless Bloomberg sues them in the next so many days. And this is Gamers Nexus, so I presume they will fight to keep it as is on principle.
Personally, I found the length of the quotes from politicians kind of tedious, but I sure wouldn’t want them to capitulate to Bloomberg after this.
Years ago, there were some development tools coming out of the Ruby world – SASS for sure, and Vagrant if I remember correctly – whose standard method of installation was via a Ruby gem. Ruby on Rails was popular, and I am sure that for the initial users this had almost zero friction. But the tools began to be adopted by non-Ruby-devs, and it was frustrating. Many Ruby libraries had hardcoded file paths that didn’t jive with your distro’s conventions, and they assumed newer versions of Ruby than existed in your package repos. Since then I have seen the same issue crop up with PHP and server-side JavaScript software.
It’s less of a pain today because you can spin up a container or VM and install a whole language ecosystem there, letting it clobber whatever it wants to clobber. But it’s still nicer when everything respects the OS’s local conventions.
reply