There is no evidence Iran has an active nuclear weapons program or has had one since the early 2000s, which even the article's author seems not to know. They have enriched uranium that could be further processed and used to make weapons, but there is no evidence they are doing so or have the capability to do so (and no, Israeli government/military sources are not reliable. They have every interest to lie about Iran having/nearly having nuclear weapons)
Seems a lot easier to have a --help flag that lists all of the options and their function. That is self-documenting (assuming the descriptions are useful) and helps with discovery. Changing the name of the file to foo--bar.exe doesn't seem any easier than writing foo.exe --bar
I too was perplexed, but the main use case seems to be when you want to share a particular configuration or need to be sure that you always use the same set of flags:
> Flags are ephemeral – you have to share the command line or wrap it in a script. Scripts depend on environment, which can break portability. Filenames solve both: the program describes itself, requires zero setup, and any configuration can be shared by simply renaming the file.
[Emphasis added] Although I find a script that wraps the command and calls it more versatile, there might be some value in this idea for some very simple cases, like example #4.
> you have to share the command line or wrap it in a script. Scripts depend on environment, which can break portability
I get the problems but I don't think I've ever had both at once. A need to portably wrap and share a specific command line for a specific program?
For the case of broadcast it seems easiest to just document the proper command line options. For the case of "unicast" I can just ask the other person what their environment is so I can craft the appropriate wrapper for them.
The area of overlap in the Venn diagram is infinitesimally narrow.
Also, you can share the generic program and then share wrapper scripts that are named for what they do rather than a series of flags. Then to share, you're just sharing a config file, script or similar that calls "whatever.exe --dir=./blah --run=12 --batch=false"
Wasn't one of Wayland's key design features combining the window manager and compositor? I am not too familiar with its history but surely there have been presentations or papers about the Wayland designers' reasoning for doing so.
When the window manager is a separate process with async communication between the WM and display server things can get out of sync for a frame or two which leads to visual artifacts. In Wayland the window manager works synchronously with the compositor so that it's never out of sync.
Yeah, that makes sense. It seems like instead of introducing another IPC protocol like this project does, there could be a compositor that loads different window managers as plugins. Then everything is in the same process and there is no need for async communication. Of course a crash in the window manager would take down the compositor, but this is already true for Wayland compositors that combine both.
> It seems like instead of introducing another IPC protocol like this project does
It doesn't introduce a new IPC, it uses the Wayland protocol with the river-window-management-v1 extension. The extension mainly defines new objects and verbs for them, but it's the same protocol.
Separate process means that the window manager can be written in any language (even, e.g.: Python).
Window Management -- Overview:
F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985.
This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme.
The Proceedings were later published by Springer-Verlag in 1986.
James Gosling: SunDew - A Distributed and Extensible Window System.
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.
Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski
X Myths
X is a colletion of myths that have become so widespread and so prolific in the computer industry that many of them are now accepted as “fact,” without any thought or reflection.
Myth: X Demonstrates the Power of Client/Server Computing
At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They’ve become unwitting pawns in the hardware manufacturers’ conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!
The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slices the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.
The fundamental problem with X’s notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program’s state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.
The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.
As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client can download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.
Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun’s TNT Toolkit). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that is both consistent across applications and customizable. With NeWS, the window manager itself was implemented inside the server, eliminating network overhead for window manipulation operations — and along with it the race conditions, context switching overhead, and interaction problems that plague X toolkits and window manager.
Ultimately, NeWS was not economically or politically viable because it solved the very problems that X was designed to create.
... or the WM loads the compositor, or the WM links to a compositor library (i.e. wlroots). The point is there are options...
Honestly, every time this topic comes up, I feel like the person complaining just doesn't want to put in the work and they are angry that they don't get an easy win. And maybe that's a good thing. Do we really need more half baked WMs?
This also means low-performing clients can make the whole Desktop stutter/freeze and it is one of the many reasons the Wayland architecture is beyond idiotic. High responsiveness is obviously far more important than avoiding the occasional artifact.
Clients (apps) should still be async in Wayland; it's just the window manager that's tightly integrated. Wayland compositors should probably use some kind of fair queuing to prevent misbehaving apps from spamming the event loop but they probably don't.
Example: Windows can only be resized when the client finished drawing the new resized window. Otherwise you would get "visual artifacts". So typical operations dealing with window management can not be async when the insistence on the nonsensical "every frame is perfect" mantra is upheld.
Graceful degradation is a thing. If you don't get a response from a client that you are redrawing, you may just put a translucent shader on the window, show the user the changing borders immediately, and then resume whenever it's ready.
Well, that's exactly what the article is about. Wayland put all together into one process I order to avoid unnecessary context switch. This protocol aims to keep the performance advantages of Wayland without giving up on separation of graphics c server and window manager.
I was responding to this comment in the article and wondering about the historical context:
> Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance.
why? because the compositor completely changed the geometry of the desktop. being 3-dimensional. now, today most wayland compositors are 2 dimensional, but they don't have to be. a window manager that works with a 2 dimensional compositor would not work with a 3 dimensional one and vice versa. the window managers listed in the article are only compatible with this particular compositor.
it seems to me that separating window managers from compositors from the start would have created the expectation that all window managers work on all compositors. that is not and will not be the case.
if all compositors start separating out the window manager then the result would be that as a user i now have to choose two components, a compositor and a window manager, and i have to make sure they are compatible.
I think wmf's comment in this thread was absolutely correct and succinct, so I won't repeat, but I think it's worth noting that many (all?) of the Wayland devs were actually Xorg devs. Make of that what you will.
Maybe the subscribers of the Post? They (reportedly) left in droves after Bezos interfered to stop the opinion board from endorsing a candidate and more recently fired nearly all international reporters. (including those in warzones)
He owns the paper and can do what he wants within the bounds of the law, but anyone is also free to criticize the decisions he makes, and subscribers are free to unsubscribe.
Criticism is about what someone ought to do, not what they can do. (these are very different)
Obviously his strategy with WA post seems to be working (for him and his ventures). He secured contracts both for AWS and Blue Origin from a seemingly hostile gov. Even if everyone unsubscribes and journalists leave, it was still a good investment.
So the shareholders of Amazon are happy. He did the right thing.
Was it moral or good for the American republic? Again, he is not an elected official so it doesn’t matter. We opted to give him so much unchecked power.
> Was it moral or good for the American republic? Again, he is not an elected official so it doesn’t matter.
Not sure where you have gotten this idea that morality or "doing the right thing" only applies to elected officials. The choices people make can be criticized even if those choices were legal or beneficial for their investors.
Destroying the credibility of a leading newspaper for some lucrative government contracts seems to be a net loss for society, but hey, at least Amazon's investors are happy and Bezos' tremendously unprofitable space company has some more cash.
Not sure if I agree with his conclusion that Dijkstra believed all programming should be done by an "elite corps" of programmers. He believed (rightly or wrongly) that undergraduate students could be taught his mathematical methods of programming, and that formal methods could make programming simpler and more manageable. Claiming he was against "working-class" programmers seems silly; anyone employed as a programmer will work for a living and so would be working-class.
His article "On the cruelty of really teaching computing science" (https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...) really resonated with me in the past, albeit it might be enforcing the assessment of the parent post regarding his more elitist approach to software development. He says:
> A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".
All right, he believed that all programming should be done by his approach, or one highly similar. He could train undergrads, but anyone who wasn't trained his way shouldn't be programming. Is that a fair statement?
This is such a common position in just about every professional industry, codified legally or as personal belief, that it barely qualifies to be called out as unique to Dijkstra.
Yes, who would say structured programming is bad these days, though maybe it wasn’t a popular sentiment at the time. Though I find this thread funny, “Dijktra was elitist, oh no, he did the gatekeeping, what horror, let’s abandon structured programming and seeing programming as a discipline altogether”.
Attacking Iran has made the entire region less safe and so far there is no evidence Iran has been deterred. They continue to successfully hit targets with missiles and drones, and they have expanded operations to successfully close the Strait of Hormuz. Seems like it would have been a lot cheaper to not attack Iran and instead to rein in Israel, an existing nuclear power that is the primary destabilizing force in the Middle East.
Both Israel's as well as Iran's and for that matter all nuclear ambitions of any nation should be reigned in, as humanity was doing for a while after the first cold war, with the progressive reduction treaties etc. From the perspective of the USA, a medium-future nuclear attack by Israel was much less likely than a medium-future nuclear attack by Iran.
Closing the Strait of Hormuz is quite easy, scorched-earth-tactics (well scorched-sea-tactics) like sea-mines are a lot easier than conquering territory.
Just look Bosnia&Herzegovina and the huge minefields that were deposited there.
This doesn't show Iran's resilience, and sea mines can be cleared.
There's a long list of cards the USA holds and somewhere down that line there are options like announcing total destruction of neighborhoods of Teheran, and advising the inhabitants to leave, starting with the richest (and thus regime aligned) neighborhoods. Just gradually announce the carpet bombing neighborhoods and provide ample time for evacuation. Watch your demands being met one by one: defuse your sea mines, if one more goes off thats another richest neighborhood gone, give up your for-energy-generation-over-enriched uranium (there is no discussion of its existence as Iran was pleading an insignificant dilution of part of this stockpile) or that another richest-neighborhood-thats-left gone.
Unlike the human-shields / hostage-taking tactics of the IRGC / ayatollah, it would target not innocent third parties nor the lives but the possessions of the regime-aligned parts of the population.
All the people you forced to study physics for the megalomaniac dreams of the regime? Allow them to flee the country (and take their inkling nuclear skills with them) and welcome them with a new free life. In the west we don't gas your girlfriends, sisters, nieces over a few hairs sticking out from under their headwear.
People repeat the patterns of their breaktrhoughs / successes.
There were many factions around the time the current regime rose to power.
Which one won? Which one was reluctantly given bargaining power by the free world? The faction that took hostages.
Ever since, whenever the regime felt threatened (internally or externally) they resort to hostage taking and human shields.
No sane person puts a girls school in a semi-used military complex, especially not in that hotbed of the middle east, with Iraq as a neighbour, Israel not much further, and while sponsoring and weaponizing groups like Hamas.
Destroy civilian areas neighborhood by neighborhood until they comply? That's not only a war crime - that would create an international humanitarian crisis and millions of refugees. Tehran alone is a city of more than 9 million people. The IRGC doesn't care how many civilians the U.S. kills. It only strengthens their case that the war is existential and America/Israel want to obliterate Iran. They have a huge stockpile of missiles and drones that are not easily destroyed. Mines are not needed to close the strait, just the credible threat of drone and missile strikes, and no ship will sail through.
"Regime-aligned civilians" is a slippery slope that is essentially collective punishment. Most anyone in Iran can be tied to the government through jobs or family, and they are not segregated by level of "regime alignment", so you would be obliterating the homes of many civilians who might otherwise oppose the government.
Genuinely flabbergasted that you came up with that strategy unprompted when not even Hegseth ("drink blood from the skulls of our enemies") has suggested it AFAIK. Your post genuinely reads like the monologue of a cartoonish villain.
The message to all other states to get nuclear weapons as soon as possible is reinforced by Trump's scrapping of the Iran nuclear deal. Even if you negotiate a treaty with the U.S. agreeing to deescalation, a new leader will likely tear it up (given the flip-flopping of the U.S. presidency, which has near total power over foreign policy).
Even returning to the negotiating table isn't enough - the U.S. and its allies may strike you anyways. (as they did last year when they killed the lead Iranian negotiator and again preemptively attacked during recent negotiations)
The generic algorithms that come with the C++ standard library are useful. Once you get used to using them you start to see that ad-hoc implementations of many of them get written repeatedly in most code. Since most of the algorithms work on plain arrays as well as more complex containers they are still useful in embedded environments.
Sad that his (and many others') dream of widespread formal verification of software never came true. He made really fundamental contributions to computer science but will probably be mostly known for quicksort and the quote about his "billion dollar mistake", not his decades-long program to make formal methods more tractable.
Makes me think of an anecdote where Dijkstra said that he feared he would only be remembered for his shortest path algorithm.
reply