Well, there's an Arduino FPGA board : the MKR Vidor 4000[0]
However I'm not sure how much people use it and if it really has the simplicity that Arduino brought to tinkering with microcontrollers. I read and hear a lot that the FPGA dev tooling is usually not really great to use and very vendor-specific, but it's something I haven't tinkered with yet so I don't really know much !
> Well, there's an Arduino FPGA board : the MKR Vidor 4000
It's an Arduino with an FPGA on it, yes. But the FPGA is practically a hood ornament: there is no support whatsoever for building gateware in the Arduino IDE, only for using a set of prebuilt demonstration bitstreams, and what little documentation Arduino has provided on using the FPGA (e.g. https://docs.arduino.cc/tutorials/mkr-vidor-4000/vidor-quart...) is extremely vague and is missing a lot of critical information.
(Additionally, some of the product specifications for the board are highly misleading -- for example, some pages refer to the edge connector as "mini PCI Express" and suggest that it can be used "to creat [sic] your own PCI interfaces", but the FPGA on the board does not support PCIe.)
You're much better off with a dedicated FPGA development board. Arduino hasn't brought anything useful to the table here.
Thanks for bringing more details into light ! As I've said I don't know much about the space and sadly suspected that it wouldn't be great, but not to this degree. It's a bit sad and it's not the "easy solution" that would have made it an easy choice for me if I were to tinker with FPGAs.
Not that you have an answer, but it makes me wonder what is the target audience for this board ?
It was released much later in the lifecycle of Zen 3 than the 4 "headline SKUs" that were launched here as well. I think we can expect the same for Zen 4.
In the first generation the 1600X was a 95w TDP part, with the 1600 being 65w. They shuffle around where the lines are, the numbers aren't always 1:1.
They listed Zen 4 at 65w TDP being 74% more efficient than Zen 3 in their slides, which implies they do want to sell a part at that spec at some point.
If your concern is purely noise/heat and so on, and not budget, then you can just buy one of these chips and apply restrictions to it, given modern chips auto-scale performance. Can feel like a waste, of course, but should result in a very efficient setup.
TDP is not a measure power consumption across the range, but only at "maximum theoretical load"[0].
If you missed the presentation, look for in-depth coverage[1]. These chips are more efficient than Zen 3, consuming less power for the same performance. The higher TDP allows for higher multi-core clocks and much higher performance, but that's not the same thing as power consumption (across all levels of performance).
Sure, if you can use the power at the high end, you can consume more power, but you'll get a lot more performance out of it.
> If you missed the presentation, look for in-depth coverage[1]. These chips are more efficient than Zen 3, consuming less power for the same performance. The higher TDP allows for higher multi-core clocks and much higher performance, but that's not the same thing as power consumption (across all levels of performance).
That's coverage from the slides, a.k.a. marketing. I don't doubt that this will be a significant performance/efficiency improvement, given the soft cap, but desktop is another thing. TDP has been correlated with average consumption, on Intel CPUs, and all the GPUs. It'd be surprising that this didn't apply to this specific CPU family.
I get what you're saying - if a CPU is given cart blanche, it might tend to just run at higher clock speeds and power draw because of the higher TDP ceiling. So it may come down to motherboard settings and OEM configurations.
I know from personal experience, my CPU rated for 105W TDP tends to consume 30W or less during my normal usage, though certainly more during heavy computation including gaming. Higher base clocks on the Ryzen 7590x (4.5Ghz) compared to Ryzen 5950x (3.4Ghz) could lead to overall higher power usage, if the increased efficiency at those clocks isn't enough to cover the difference.
You're right, I misspoke ! For Zen 3 they announced the 5800X and released the 5700X later (with the same TDP as the GP's 3700X), whereas for Zen 4 they announced the 7700X and the 7800X will probably be released later.
Indeed every CPU announced here has a higher TDP than the previous generation, which isn't the best. Hopefully lower TDP SKUs come out as you mention.
Id assume that the 7700X is basically the 1:1 successor for the 5800X and the reserved the 7800X name for the X3D equipped version that presumably comes later.
They might release a 7700 without the X.
The parent is correct, in theory .eu requires residency or citizenship in order to register a domain[1].
After Brexit holders of .eu domains that did not meet the criteria lost their domains[2].
And the .eu is not the most restrictive ! I am a French citizen but live outside the EU, so I can't get a .fr domain (at least, again, in theory - haven't tried in practice) but I could get a .eu one.
I have dabbled with quite a few assembly languages (8051, MIPS, A64 and a bit of x86), the first and second of which I learned in school. To be honest if your teacher is good and the class is well prepared, it should be pretty nice !
As fmax says in their comment it's not that different than learning any other new language : there are some key concepts and ideas which you'll need and the mnemonics, which are the assembly keywords like `ADD` (better to have a searchable reference handy). But all those things can be acquired by experimenting with it and writing simple programs. On top of that, you say the course is on computer architecture so I bet you'll have a very useful overview of all those concepts that are useful for assembly writing ! peterkelly's link looks very useful for that purpose as well.
For that you'll need to setup some sort of environment where you can write, assemble and run your assembly code. jakuboboza has some good ideas to check with previous students to know what can of environment you need.
Eventually you can check an even simpler assembly like the 8051 that has very simple emulators and IDEs available.
Or, if you want something a bit more game-y you can look into Zachtronics' puzzle games[0] that often have an assembly-like language and come with a manual, which can help you become familiar with the basic principles. TIS-100 is only assembly writing, Shenzen I/O has a bit of wiring/"electronics" on top and EXAPUNKS makes you "hack" systems using little bots written with this assembly.
I found that knowing a bit of assembly is quite useful and interesting to learn, I hope you'll have fun with it !
You can already stream games from a Linux machine with Steam and then get to the desktop. It's baked in, but I'm not sure you can directly stream the desktop without launching a game before, but it works pretty well. I managed to play a game running on my Linux desktop in the UK while being in mainland Europe ! Wasn't a bad experience at all.
Minecraft is one of the biggest games of my teenage years, starting in Alpha, and I always was a bit paranoid, making backups and copies of things. As the sibling comment points out, you can go back in versions from the game launcher itself and I recently did a nostalgia trip loading up those worlds again, seeing how the game has evolved, how my playing style evolved... By loading them into a few intermediate versions, you can even get them to load in the latest one ! I really appreciate to be able to do that. (Even if I still have a couple of copies of the older versions I could play with !)
To be fair, Valve already has a way to control mostly what is used by Steam and the game. They have their own runtime that uses (or can, can't remember if it's always the case) containers to create a controlled environment.
I have had issues sometimes with library/drivers versions on my rolling release preventing me from running everything natively, but each time using the runtime version of Steam allowed me to play.
They have information about it all over the place, I can't find exactly the page I wanted, but here[0] is some more information about it from their repository.
The thing is, you can change a lot of those things to match what you want. You can toggle the application menu, which works more like the windows menu. You can use something like dash-to-panel [0] to make the top bar into something useful.
I know that in Firefox you can disable the window bar to make it look a lot cleaner with a top bar.
Here is a screenshot of how my GNOME looks [1]. I don't have the application menu because I use an app launcher, so it doesn't bother me that much.
That's an investment you have to make if you want it to look like you want to. Maybe you just want to have a DE that works for you without tweaking it, which I understand. But I'm pretty sure you could make a GNOME desktop you like given the time.
Having tested multiple desktop environment and window managers, it's pretty great having such a diverse pool of choices : you can really ditch GNOME completely if you don't like it.
The problem isn't that you can't configure GNOME to behave to your preferences. The problem is that GNOME makes it hard to do so, and that's a philosophical decision the project made.
If I'm about to spend time customizing my DE to match my preferences and habits, I'd much rather spend the time on something that is made to be customizable.
I don't think that actually is a problem though. For specific GNOME apps it's true, they tend to avoid having a lot of configuration settings. You can just avoid using those apps and use other ones.
The one part you can't replace is the shell, but you can pretty much configure every aspect of that using extensions. If you don't like the way the shell operates on a fundamental level, then you would probably be better served by using a different desktop.
You're making my point for me. You're suggesting I spend additional time cobbling together extensions (which presumably can end up unmaintained and/or break?) and swap out some applications.
This feels like ordering paella at a restaurant when I don't like seafood. Sure, I can eat around all the sea bits. But there's lots of other options at this restaurant, so why the f* would I order paella, knowing it has seafood I don't like?
I'm not gonna tell you not to order the paella, or that the paella is bad, or that the restaurant is bad, or whatever. But don't push the paella on me either please ;)
I'm not sure I understand the point -- that's a different complaint entirely. The "cobbling together extensions and swapping out applications" is the customization, that's exactly what you asked for initially.
Edit: If the issue is that some extensions break and become unmaintained sometimes, that's unfortunate, but the only other solution there would actually be to put heavy limits on the extension API. Which would probably not be to your liking either because it would actually reduce customizability.
I'm afraid I don't understand -- the extensions are configurability. That hasn't been removed. If you didn't have an API to configure these things, there would be no way to do it at all, so it still sounds like you're asking for something contradictory. What would help here? What would be the benefit of removing the extension API, and what would you replace it with?
It sounds more to me like you're twisting these things to make them seem contradictory.
> the extensions are configurability
And this is an inadequate mechanism.
(For me! If it works for you, that's great! Me, I like to be able to configure bars and widgets and menus and stuff wherever I want with a few clicks, which is why I run Xfce. Far be it from me to say there should only be one true desktop)
I'm not sure what you mean twisting. If you're asking for the extension API to not be there, I think that would result in a strictly less configurable program. If that's not what you're asking for, then please clarify. Also, I'm not sure what you mean inadequate, the extension API is the internal API of the shell. You can use it to do anything that the shell can do. How could it be made adequate? You can install many extensions to configure the panels and menus in just a few clicks.
Edit: Somebody could probably make an extension to make the shell look and act like XFCE if that was really desired, for whatever reason. I don't think XFCE users would care much, but I just mean this as a way to illustrate what level the extension API sits at -- it's a level below the panels and menus and stuff.
I'm sorry, please don't assume bad faith, I'm not refusing. I just don't understand how opening a configuration dialog and doing a couple clicks to install an extension that changes the panels, is different from opening another configuration dialog and making a few clicks to change the panels. It seems exactly the same to me. I don't have any preference towards either of these, I'm just interested to hear why it doesn't work for you.
For me, it's very simple. There are certain things that I must have in a desktop environment (DE) --- for example, having a 3x3, 2-dimensional workspace. As far as a DE is concerned, I want to be a user of the DE, not a developer of the desktop environment.
The problem is that the extension API is fundamentally unstable, and so extensions which provide the functionality that I consider a must-have, are unreliable, and may break in future versions of GNOME. I don't want to be in the position of debugging an extension which stops working in a future version of GNOME. I may be a kernel programmer, but as far as the desktop environment is concerned, I just want to be a user of it. And if an extension breaks, and I have to figure out which other extension might have the feature that I want, but which might require painful configuration somersaults after successive new GNOME versions, the answer is very simple. I'm just going to say, "No Thanks". KDE/Plasma supports what I consider to be fundamental key functionality, and I don't have to mess with it. And so GNOME is just not for me. If it works for you, great! But an extension API which is not stable, and when what I consider core functionality can only be provided by extensions which are resting on top of quicksand, is not going to be persuasive answer.
Hi Ted, thanks for responding. The extension API is similar to the kernel's driver API, with the same caveats -- you can use it externally, but you need to track upstream for breaking changes, because upstream is always going to need to have the ability to refactor and deprecate things, otherwise they get stuck maintaining deprecated/crufty APIs forever. And yes, I am suggesting that making a stable extension API for the shell would probably be about as difficult as making a stable Linux driver API. There is not really any consensus on what a GUI shell is supposed to look and act like, as you can probably tell from all the arguments all over the years.
If KDE has a solution to this problem in the works, I'd love to hear about it, but AFAIK this is not solveable with code, because it's a headcount problem, not a technical one. Otherwise my suggestion would be the same as the kernel developers say to someone using out-of-tree drivers: either get your extension upstreamed, and deal with the long review process from the shell developers, and be prepared to explain in extreme detail why you need 2d workspaces and why it's worth it to have upstream maintain that... or just don't update your shell until the extension gets updated. This isn't really a Gnome specific problem either if you ask me, I haven't seen any desktop compositors for Linux that are active and offering a fully complete and stable API, because turns out it's not an easy thing to do.
KDE has solved the problem for me by providing 2-D workspace as a core feature, and not relegating it to the slums of "you want it, write your own d*mn extension".
GNOME has chosen not to do this. And so, GNOME is not for me, because I consider a 2-D workspace a "must have" feature. And so I will choose KDE over GNOME, because as a user (and I'm not interested in becoming a Desktop developer, sorry; I'm also not a web browser developer, or word processor or spreadshet developer, either. We can't be developers for everything), KDE meets my needs as a user. GNOME does not.
My main complaint with GNOME is that their answer for "you don't support feature X" is not, "yeah, sorry, we have an opinioned design, and go f*ck off", but rather, "Stop complaining, we have an extension for that". And so they don't understand that unstable extensions is not an answer to a user complaint that a feature doesn't exist. If they don't want to support a feature, that's fine. But don't try to use the lame excuse, "there's an extension for that", since they don't want to admit that they are asking users to rely on something that will randomly break.
If someone wants to use ZFS, I'll tell them that this is not supported by Linux. If you really want ZFS, use Illumos or FreeBSD. If you use Linux with ZFS, and it breaks, that's not my problem, and I'll be first to disclaim that Linux support ZFS. Because it really doesn't. There may be 3rd party developers who are trying to make that work, but I would never recommend to a user that they use Linux/ZFS, since if they need newer hardware support which is in a kernel not supported by Linux/ZFS, or their distribution has updated their default kernel to a version that doesn't support Linux/ZFS, they shouldn't come complaining to the Linux kernel community. Unfortunately GNOME is trying to have things both ways.
That's great, I support you using KDE. But the fact is, if you really wanted that feature in core Gnome, someone would have to advocate for it, implement it, and then get that feature upstreamed, and then someone will have to maintain it upstream, indefinitely. An alternative to that would be for someone to write the extension, and then maintain it by tracking upstream, indefinitely; both are about the same amount of work. So it's not clear to me why you're complaining about having to write your own extensions -- this is just how open source works. You have to do the same thing in KDE if you decide you want to add some new non-default functionality that doesn't exist there too. It's not any different because it's a desktop and not a kernel, or a web browser, or a spreadsheet, or whatever. I'm happy that you could use KDE and that it works for you, but from my perspective Gnome is not doing anything weird or strange that KDE is not doing, other than having a different default design of what workspaces are supposed to be.
My only real complaint is advocates like you who try to claim that an extension is a valid solution to a feature request. Because it really isn't. People spend a lot of time customizing their environment to meet their needs. And they often don't have a choice not to update some package like a GNOME Shell. The problem is that there are huge numbers of dependencies, and if you hold back on updating GNOME Shell, you can't update a potentially huge number of other packages, and you risk your desktop or laptop installation becoming unstable.
So the "just a few clicks and you can install an extension" is really a very weak, naive argument. One might even say, one made in bad faith. I don't tell people to use out-of-tree kernel modules either, because that's not really a solution for exactly the same reason. Instead, I tell them, yeah that sucks, I suggest that you not buy Nvidia hardware. :-)
Please don't assume bad faith. Extensions can be a solution to some problems, but they're obviously not perfect -- I'm not saying they are.
>The problem is that there are huge numbers of dependencies, and if you hold back on updating GNOME Shell, you can't update a potentially huge number of other packages, and you risk your desktop or laptop installation becoming unstable.
So just to be clear, that same problem propagates to upstream, which is exactly why the extensions break. If they wanted the extensions to not break so much, the alternatives there that upstream has would be:
- Hold up the release so that everyone gets a chance to update their extensions. This causes sweeping problems because now everything else is delayed if an extension developer is slow, and this may not even help if the extension developer has truly vanished, because then nobody will be around to update the extension. Gnome switched to time-based releases a long time ago to get away from those problems.
- Merge the extension upstream. There are a large number of extensions, and some of them conflict with each other, so this is sadly not feasible to do with every extension that everyone wants, and some people will still be unhappy because their extension was not popular enough to get merged.
- Limit the extension API to a small group of stable functions. This will reduce the total number of extensions, and people will still be unhappy because some things will not be part of this API (e.g. it's unlikely you'd get the full lower-level workspaces API that allows you to implement something like 2d workspaces).
- Don't allow extensions at all. Now if you want to change the shell's behavior, you have to do a hard fork.
So yeah, I agree extensions are sometimes not a valid solution to a feature request, but the problem is that every other solution is even worse, at least for Gnome anyway.
>I suggest that you not buy Nvidia hardware.
If you want to play this game, I could suggest that you just not use 2d workspaces. But I won't -- I think you deserve to use that feature if you want it. And if I did buy nvidia hardware, I would use nouveau :)
This big difference between the Kernel Modules and GNOME Extensions is that we in the kernel community do not encourage out-of-tree modules. Indeed, they are strongly discouraged. So they out-of-tree modules are never considered an answer to anything.
The kernel interfaces which are supported forever, and for which we will never break userspace, are the system call interface. We don't break that, because to do that would be to break faith with our users.
With GNOME, features are removed, and the lack of features are excused, by saying, "there's an extension for that". That might be a fine answer, if the extensions API were treated like the system call interface, where we do keep things stable. If the extensions API is not stable, then you shouldn't be encouraging out-of-tree users of that API. Because you're effectively promising that you will break them, all the time.
There are times when we in kernel land will say, that belongs in userspace; it's insane to put that functionality in the kernel. But when we do that, we offer stable system call interfaces so that you can do it in userspace, and users can trust that it won't break.
The bottom line is if the API is not stable, then there should be no external users of that interface. Which is why you shouldn't use Nvidia drivers. They are a bad idea. Similarly, people should not use GNOME extensions, unless they like being randomly broken at a distro upgrade.
And yes, I will not use 2d workspaes with GNOME, because I refuse to trust in extensions. My solution is to simply not use GNOME. Xfce and KDE support 2-d workspaces as core features. If GNOME can't, then to hell with it.
>This big difference between the Kernel Modules and GNOME Extensions is that we in the kernel community do not encourage out-of-tree modules. Indeed, they are strongly discouraged.
It's not different, it's mostly the same with extensions. They're strongly discouraged unless you're able to track upstream and follow the release. If someone can't do that, then don't depend on them to make an extension. You wouldn't make such a person a kernel maintainer of a key feature either.
>That might be a fine answer, if the extensions API were treated like the system call interface, where we do keep things stable.
That comes back to what I was saying earlier. The system call interface is very small and very limited compared to the total size of the kernel's API. It's not the same as the GS extension API, which is a huge API that allows access to various internals. The equivalent to create a "syscall API" in GNOME shell would be one of the options I said earlier -- "Limit the extension API to a small group of stable functions" which would not please you either, because that would essentially be removing APIs and would cause even more extensions to break and become impossible to implement.
Of course if you decided to stabilize everything then you would be stuck with a project where you can't refactor anything -- imagine a future for Linux where you have eBPF hooks across every function and internal structure, and you can't change any of them ever, because those kernel structures are now external API accessed by userspace. If you want GNOME to stabilize their internal API, that's really what you're asking them to do. Is that a good explanation of the problem? I'm trying to explain here why this is actually a really nasty technical minefield, and ultimately has little to do with release policy, or with any particular architectural decisions made by GNOME. There are basically zero active open source desktops that have a comprehensive and stable plugin API. KDE doesn't do it here either -- these particular areas are not even possible to change there with plugins, you're just lucky enough that the core workflow works for you.
>unless they like being randomly broken at a distro upgrade.
This is not strictly true. Just FYI, I've seen some GNOME-based distros that are starting to bring certain extensions into their release cycle, and make those part of the upgrade. But of course that falls on the distro to support the extension and do the testing before they ship, so the extension has to pass a certain quality and usefulness threshold first for that distro's users. If you get stuck using a GNOME-based distro in the future, you may want to check what their policy is there, you may be surprised (although I don't think any are shipping 2d workspaces).
>Xfce and KDE support 2-d workspaces as core features.
That's great, you should use those if those are what you like. But here is my perspective: If some XFCE or KDE developers (who know how to implement 2d workspaces) wanted to spare some time to revive the 2d workspaces extension in GNOME, and keep it working during distro upgrades, and support you doing what you like, I don't think any GNOME people would have a problem with that. Similarly, if it were possible in a reliable way, I don't think anyone in KDE or XFCE would have a problem if some GNOME developer maintained an optional XFCE or KDE extension to make those use a GNOME-style workspace overview, for those who prefer that design.
I was using GNOME when 2-D workspaces was a supported feature, and when it was removed, people told me, "don't worry, use an extension; the feature isn't really gone". The problem is then the next time my distribution updated to a new version of GNOME, things broke, and I had to scramble to figure out how to get a working desktop environment again.
Fool me once, shame on you. Fool me twice, shame on me.
Or just switch to a DE that is willing to be receptive to the needs of its users. Again, GNOME used to support 2-d workspaces. This feature was removed, deliberately, by the GNOME developers. That's their prerogative, but don't try to fool users by claiming that extensions are the solution. Because extensions break. Frequently. Often. And so they can't be depended upon. If it's a critical part of your workflow and usage model, and the DE doesn't support it except via an extension API, then run away. Run far, far away.
More generally, GNOME has been in the feature removal business for a long time. So even if something is in the supported feature set today, there is no guarantee that it won't be removed tomorrow. And that's one of the ways in which it's not like kernel development. Once a userspace visible feature lands, it won't get removed. Linus will yell at you and revert your changes if you break users in that way. GNOME is frequently removing features, and so as a result, they can't be trusted. Moving something to an extension is a negative value add to users. Worse, it breaks trust with your user base. Because GNOME has done this to me, it's going to be a long, long time before I trust GNOME again.
Hi Ted, thanks for replying. Those statements you've made are untrue. Just like kernel drivers, extensions don't break when someone is maintaining them. To be clear, the issue here is not that the DE was not receptive, the issue is that the extension developer disappeared. All the hundreds of GNOME developers didn't get together and collectively decide to get rid of that extension, the one person who was working on it likely just lost interest. Nobody stepped up to fill the space, so now it becomes a manpower issue. That's the way it goes in open source. It would be the same issue if the feature was upstream and the maintainer disappeared.
What you're saying seems to me the equivalent to saying "If a kernel driver is a critical part of your workflow and usage model, then then run far away, the kernel driver API is unstable and the driver maintainer might get hit by a bus." Because as I have said before, the shell extension API is really not similar to kernel's userspace -- it's closer to the kernel's driver API, in that you get complete access to the shell's internals, you can muck it all up and crash things if you're not careful, the API is unstable, you have to follow upstream closely to really take advantage of it... but if you do all that then it's a very powerful tool, and you can do things that are not possible in "userspace" (i.e. outside the shell).
And the fact is, the kernel does remove old and broken and unmaintained driver APIs. That's your prerogative to do to that, as it is GNOME's (and KDE's) prerogative to remove legacy APIs and features that are not pulling their figurative weight in usefulness. I'm not trying to convince you to use or trust GNOME, I'm happy that you're using KDE and it works for you. But I wish you would not say these falsehoods without an understanding of how GNOME is actually developed, because from my perspective the technical process is extremely similar to that of the kernel, and heavily inspired by it. So please don't forget, the apple never falls far from the tree. If you have some insights on how to plug this maintainer gap that you think GNOME is suffering from, then let's talk about that.
This is incorrect. 2-D workspaces used to be part of the GNOME core feature set. It was removed from the core feature set, and the excuse was, "oh, if you really want that, you can develop an extension". That's not an answer, and that's not allowed in the Linux kernel development paradigm.
As far as we are concerned, out-of-tree modules do not exist. The module interface is only for in-tree users, which are fully supported. GNOME takes the position, or at least apologists like you, that out-of-tree GNOME extensions are a good thing. As far as Kernel developers are concerned, out-of-tree modules are never an answer. Device drivers should live in the kernel. Period. If Nvidia chooses to do otherwise, that's their problem. But we didn't kick Nvidia out of the kernel.
GNOME kicked 2-d workspaces out of the core DE, because they didn't want to support it. They think that they want to keep things "simple" for their users. Google "GNOME Feature Removal" and look at the history. They took perfectly working features and ejected them from GNOME. We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.
Please stop making these insulting comments calling me apologist, this is rude and unhelpful; you're a better person than this. I've respected your kernel expertise for a long time and it's disappointing to be treated this way. This is the kind of behavior that pushes people away from open source. I'm only here to help explain how this works and to help get the issue fixed, I would do the same if you were making such statements about KDE.
>We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.
GNOME unfortunately does not have enough maintainers to do this. If you'd like to help out, please contribute, or help direct some others to do so. That might mean helping to maintain some extensions that you're using. If you don't want to help, and you want to use KDE, that's understandable too -- but please understand what the real issue is.
>Device drivers should live in the kernel. Period.
It would be great if it was technically possible to do this with GNOME, if this is your goal, I would encourage you attempt to merge all the hundreds of extensions together into one big tree, resolve all the conflicts, and then maintain that. It's probably going to be a lot of work, and will break a huge number of things, and if you don't want to do it... well now you understand why GNOME maintainers don't either. Until that happens, people have to stick to another approach: extension maintainers just have to use CI to check their extensions against master and keep it updated.
Well, because I'm having to install third party pieces which may or may not break stuff, may or may not be supported for long, may or may not break on the next update, in order to achieve a base level of configurability which it seems like DE designers don't want you to have in the first place.
Maybe they fixed things in the last few years, I have no idea, but last time I had to use Gnome 3 it broke existing DE muscle memory of using all sorts of environments across all sorts of platforms, and made it hard to discover how to change anything. Having to then install third party pieces to achieve minor change is not something I feel is an adequate replacement, particularly coming from systems where easy, built-in configurability comes as standard.
Again, if that all sounds fine to you, more power to you. To me it's an opinionated DE that tries its best to push its own ideas of usage on the user, and hides any/all options behind an API rather than exposing them to the user by default.
Why would I bother with such a DE when I can find one that supports what I want to do out of the box?
You're making a distinction of "third party" here but I don't understand why that really matters for configurability, for example it's no different from installing an unoffical XFCE panel applet, or using a third party file manager, etc. In the gnome shell, the extension API is built-in and standard. That is the configurability. If you're asking for specific panel settings to be included by default, that really isn't possible in a way that would please everyone -- you can look at the sheer number of panel extensions there are to see why that is the case. Again someone could make one to make it look and act exactly like XFCE's panel, but that would just be yet another option. Does that explain it? It's not really possible for the shell to act the way you're asking.
I support you using XFCE if that's what you want, but if you're asking for changes to be made in Gnome, those could probably not be made without causing much worse breakage. If you're not asking for that, then never mind, I misunderstood :)
> Right, so that is a problem, but it's a different problem from lack of configurability
Lack of out of the box configurability, lack of ease of discovery of configurability, lack of dependability on third party pieces (which may be essential to my workflow, that third party widget in Xfce isn't).
That initiative looks like a good move, I don't mean to disparage that.
> In the gnome shell, the extension API is built-in and standard. That is the configurability.
And that's not a good mechanism for me, as discussed.
> If you're asking for specific panel settings to be included by default
Yes, that's specifically my preference, for a system the user can configure, easily/out of the box, without relying on third parties to patch some really simple stuff back in.
> It's not really possible for the shell to act the way you're asking.
I'm not asking the shell to act any particular way, nor am I asking for changes in Gnome. I have had no real interest in Gnome since the 2->3 transition and this approach is part of that.
>Yes, that's specifically my preference, for a system the user can configure, easily/out of the box, without relying on third parties to patch some really simple stuff back in.
I personally would describe that approach as actually more lacking in configurability, because with that you're limited to only the built-in settings. In my opinion all those could be improved with further improvements the extension system. In general I also see the line between "third party" as being blurry in these open source projects, because any random person can contribute something. But in the end, you deserve to use something that is to your preference.
>I'm not asking the shell to act any particular way, nor am I asking for changes in Gnome.
Sorry, I guess I'm confused as to why you'd be talking about technical issues with GNOME, if it's been totally irrelevant to your interests for the last 10 years, and you don't even use it. If you're not interested to give constructive feedback or try to fix the issues, or try to describe different ways of achieving your workflow, then I would say I'm not really interested to discuss complaints about these things.
One issue with extension is that it's not official. For example from the very extension you linked (dash-to-panel) I can find out, that Gnome 40 support issue (#1265) is not closed. Gnome 40 was released almost 3 months ago and it is default in Fedora 34. Imagine someone upgrading and breaking his workflows completely.
That would be OK for some minor adjustments, when user can live without this extension for a while. But for something as major as dash-to-panel, it should be official and updated synchronously with main project to be a proper option IMO. That's my reason to avoid this extension for now. It might be good, but I don't want to depend on it.
That's fair, and I agree it would be much better if it was officially supported. I'm on a rolling release distro but I had to freeze all my GNOME packages to stay on 38 because of the issue you mention.
But I chose GNOME knowing they have a tendency to break a lot of extensions with new versions, which is honestly quite a pain and something I understand many (if not most!) don't want to deal with.
That's really interesting to me, because in Spanish we have the exact same word, "azar", but from how I understand it it's just randomness (apparently according to the dictionary some of the other meanings have a negative take). We have the same expression too : "juegos de azar" for games of chance/gambling.
It's also quite close to the french equivalent : "hasard", which also means randomess and has similar usage, with "jeux de hasard".
In all cases it's an interesting fit with the Chatroulette reference.
according to wiktionary, they both originate from Arabic اَلزَّهْر (az-zahr, “the dice”). presumably frenchmen were simply wont to add a bunch of silent letters.
The "h" is necessary to indicate there is no liaison with the previous word and the "d" is an indication that that derivative words use a non-silent "d" (like "hasardeux").
Zar in Balkan languages – it exists in e.g. Romanian and Albanian as well – is an Ottoman-era loanword from Turkish, which in turn borrowed it from Perso-Arabic (i.e. possibly directly from Arabic, but more likely through Persian mediation).
which looks like 'hazard' in english, which is (from mw dictionary)
* a source of danger
* the effect of unpredictable and unanalyzable forces in determining events : chance, risk
* a chance event : accident
* a golf-course obstacle (such as a bunker or a pond)
* a game of chance like craps played with two dice
i'd guess there's a connection? i'm no word historian person though...
According to the Oxford Dictionary, the origin of hazard is as follows:
Middle English (in hazard (sense 3 of the noun)): from Old French hasard, from Spanish azar, from Arabic az-zahr ‘chance, luck’, from Persian zār or Turkish zar ‘dice’
It bears mentioning, as an interesting fact that I just found about, that azzahr comes from Andalusi Arabic, and that zahr (in Arabic) means 'flower', from which the Spanish word azahar (the white flower on some trees such as orange trees) comes.
Etymologies from the most official Spanish dictionary:
azar: Del árabe hispánico *azzahr, y este del árabe zahr 'dado'; literalmente 'flores'.
azahar: Del árabe hispánico azzahár, y este del árabe clásico zahr 'flores'.
In Italian "gioco d'azzardo" has the exact same meaning as "juego de azar". But an "azzardo" is a dangerous or risky behavior or action (the implication being that doing it would be a gamble).
The Spanish pronunciation of orthographic z as /θ/ is rather late, post-16th-century. So, I would presume that French could have borrowed the word earlier than that.
I believe it was /ts/ and /dz/ before that, depending on if Old Spanish had ç or z. It's not like it went from [s] to [θ], which I think is what some people assume.
Wikipedia for Old Spanish says there were two distinct variants of z:
The affricates /t͡s̻/ and /d͡z̻/ were simplified to laminodental fricatives /s̻/ and /z̻/, which remained distinct from the apicoalveolar sounds /s̺/ and /z̺/ (a distinction also present in Basque).
That's pretty interesting. I don't have any experience distinguishing between sounds like that but reading around I start to wonder if I might produce such differences without being aware of it.
Yes, I would guess that in Brazilian portuguese the expression "jogos de azar" comes from this original meaning of the word "azar", as randomness. But the isolated word "azar" took on the specific meaning of "bad luck", which kind of leaked to how one would interpret "jogos de azar" around here.
However I'm not sure how much people use it and if it really has the simplicity that Arduino brought to tinkering with microcontrollers. I read and hear a lot that the FPGA dev tooling is usually not really great to use and very vendor-specific, but it's something I haven't tinkered with yet so I don't really know much !
[0]: https://store.arduino.cc/products/arduino-mkr-vidor-4000