In this case, because you're an EP legislator and Hungary is part of the EU.
tal
From his other article linked from the submitted one:
https://batsov.com/articles/2025/04/07/emacs-startup-time-does-not-matter/
Emacs startup time doesn’t matter.1 Why so? Because of how people normally use Emacs, compared to some other editors:
If you’re the type of person who uses Emacs in the terminal, you’re likely using
emacs --daemon
The basic idea that he's got is not new, which is that the solution to emacs having a long startup time compared to most terminal editors is to start it once in the background when a user session begins and then to never start it up more than once per user session. You should just connect to an existing lone instance using emacsclient
.
Some software packages that one really wants to open quickly have this approach optionally available, like the virtual terminal program urxvt
with urxvtd
.
I fall into that "terminal user" camp that he thinks should be using emacs --daemon
, but I can't agree on the "instance per user" thing. I use mostly instance per-project.
-
Some operations are blocking. If you do one of these in emacs while working on one thing, all of your other unrelated things for which you may be using emacs are also blocked. Yeah, there are ways around some of that and some mitigations. But for many things, the concept of something that blocks the whole instance is normal functionality.
dired-do-shell-command
, say. If you want per-instance stuff, then that needs to be gone and something closer todired-do-shell-command-async
needs to be the only option. -
The minibuffer is instance-global. Leave an active minibuffer in one frame or terminal running emacsclient and you can't do anything elsewhere. It's hardly reasonable to ask me to not switch away from using the minibuffer on one task so that I can go play music in emms or edit a Threadiverse comment. You'd have to make the minibuffer operate at another level than instance.
-
Frankly, emacs doesn't make much use of multithreading internal to an instance, so one of the better ways to make use of parallel processing is to have concurrent instances. The rate of increase of serial computation no longer doubles every eighteen months, and has not since the early 2000s. Software's only route to getting more compute performance is parallelization. Yes, one single emacs instance is an easy way to avoid work on mitigating startup time. But using multiple instances is an easy way to get parallelization. Is it easier to fix startup time or parallelize emacs everywhere? I strongly suspect that the parallelization task is harder.
-
There is state that is per-instance all over that I want to be per-project. Take the buffer list. There is no standard convention for grouping buffer lists below this level. And yeah, I know that the article author is the dev of projectile, and projectile groups some things around projects, but not everything is a projectile project.
dabbrev-completion
candidates.next-error
is per instance. If you want the instance of emacs to be a virtually-irrelevant technical detail merely used to optimize startup time, then everything instance-global like that needs to be purged from emacs. Everyone has to settle on one convention for "grouping" state like the above presently-instancewide things.I do run one fairly persistent emacs instance, which I use mostly to do email, since mu4e locks the mu database and isn't friendly to multiple concurrent emacs instances touching that. But there's just no way I'm switching to one emacs instance globally. I've tried it before, and the software isn't there yet.
If it became essential to use an emacs daemon to deal with startup time, I'd favor an approach more of the sort that I believe a few other, non-emacs packages have used. You start your "daemon emacs" instance. It completes startup. But after that, it does only a single task, never gets used for anything else. When someone spawns what would normally have been a new emacs instance, that "daemon instance" does a fork()
. That's a fast operation. Might need to perform a few post-fork operations, but they shouldn't be substantial. Has to deal with shared system resources that cross fork()
, like open file descriptors or shared memory or whatever. Needs to chdir()
to where our emacsclient
-like program was invoked. But that should be limited in the amount of work involved. Now you have a decoupled instance that doesn't have anything to do with the "daemon instance", but also doesn't need to do emacs startup until it's usable.
Emacs is highly portable, runs on many different platforms. Not all of them, especially the old ones, can fork()
. It can run on MS-DOS, for example. But I'm okay having "fast startup" being some kind of optional non-core-functionality perk that is only available on some platforms, especially since I'm pretty sure that all modern platforms have fork()
.
Note that that doesn't permit for some other things that the "per user instance" model permits for that some users might want, like a shared global kill ring (though I could also see that as undesirable, stomping on state across projects, polluting kill-ring history). It doesn't reduce systemwide memory usage as much (I don't care much about that). But it does avoid a lot of problems that the "one instance per user" model brings with it.
missing...shooters
What do you mean by this? Sometimes people are referring to shmups in using the term, but that's on the list. You mean lightgun games? Rail shooters?
One lawmaker on the trip confirmed to POLITICO that the Parliament officials joining the delegation were offered Faraday bags — special metal-lined pouches that block electromagnetic signals — by the Parliament’s services and were also advised to be cautious about using public Wi-Fi networks or charging facilities.
If you legitimately have concerns, why wouldn't you just leave your phone at home? It does no good to have it with you if it can't come out of a bag. If you must have a phone there, just get a burner one.
I've never used Synology NASes, but one feature that Synology NASes have that I found interesting and unusual was their ability to glue drives of different sizes together, what they called "hybrid RAID". No single-drive point of failure, but permits for using drives of different size without wasting a ton of space.
While this isn't, internally, all that technically complicated to do
internally, I understand that it's just slicing the disks up into a bunch of Linux LVM logical volumes and merging those into an md device, keeping in mind where the logical volumes are located. You can build something like it on a Linux machine with LVM and md. However, it isn't something that other NASes that I've seen provided.
Last I looked, Unraid couldn't do it, and QNAP couldn't do it.
Based on a quick search, it sounds like Unraid still can't do that.
It's open source, would be hard for an entity to take over, and permits for third party clients.
There are many subreddits on Reddit with no analog on the Threadiverse.
There are also a number of subreddits that contain information not available elsewhere.
I don't log in to Reddit anymore, but I'll search for answers on Reddit and skim a couple of communities read-only.
There was some recent cloud infrastructure project that was driven by France and Germany:
https://en.wikipedia.org/wiki/Gaia-X
I don't know whether this is that or some new thing -- the article isn't really clear what this "push" is. If it's that, then I don't think that Hetzner is a member, because searching for "hetzner gaia-x" doesn't turn up anything.
It was periodically a topic of conversation on /r/Europe.
It doesn't look like Gaia-X is dead, at any rate, since I do see a news item posted on their web site two weeks ago:
So I assume that it continues to be a thing.
I'd guess that it's probably broader than LGBT issues, if they're taking
and the article is not clear on this, and the source anonymous
issue with hate speech laws in general.
“No free speech, no deal. It is as simple as that,” the Washington source said.
Hmm. If that's correct, that's interesting. I wonder if similar criteria might apply to other countries to which he's talking on trade.
It looks like in the past few years, in the EU, there's been effort to require member states to prohibit hate speech. I'm not sure if that's gone through.
https://pmc.ncbi.nlm.nih.gov/articles/PMC9086657/
Criminalising Hate Crime and Hate Speech at EU Level: Extending the List of Eurocrimes Under Article 83(1) TFEU
In September 2020, President von der Leyen announced the Commission’s intention to propose to extend the list of EU crimes or Eurocrimes to all forms of hate crime and hate speech, as later reflected in the Commission Work Programme 2021.
In the US, member states may not prohibit hate speech; hate speech is not a legal concept here, and speech that might be classified as hate speech elsewhere is protected under the First Amendment.
EDIT: Though there is a related concept in the US of a "hate crime". A crime's sentence
and the crime itself cannot simply be engaging in speech
may be elevated if done when the motivation is hate against some protected groups. That is, the First Amendment would prohibit any form of government ban on saying saying "transexuals are abhorrent". But it is permissible in the US to pass a law to punish someone who physically assaults a transexual person, not merely for their assault, but also for performing assault with a specific motivation, if that motivation can be shown to be that the victim was transexual.
https://en.wikipedia.org/wiki/Hate_crime_laws_in_the_United_States
Hate crime laws in the United States are state and federal laws which are intended to protect people from hate crimes (also known as bias crimes). While state laws vary, current statutes permit federal prosecution of hate crimes committed on the basis of a person's characteristics of race, religion, ethnicity, disability, nationality, gender, sexual orientation, and/or gender identity.
Forty-seven states and the District of Columbia have statutes criminalizing various types of bias-motivated violence or intimidation (the exceptions being Arkansas, South Carolina, and Wyoming).
With the rods of the eye. Your eye doesn't consist entirely of rods.
The Wikipedia article says that your cones should be more-sensitive to flashing at higher frequencies than the rods. The rods are what are what pick up light when you're viewing something through the corner of your eye. What I experience with these bulbs is the opposite of what I'd expect from that: flashing is noticeable and annoying when viewed in my peripheral vision, but gone (well, or on the edge of noticeability) when in the center of my vision.
EDIT: Well, to be fair, I guess I don't actually know that they don't have some sort of power control circuitry, haven't pulled one apart, so I guess I shouldn't say that they're 60 Hz. But unlike typical LED bulbs, they're narrow; these corncob bulbs don't have the bulge for space for an electronic ballast. If they don't have the ballast, I'd be expecting them to run off the wall power directly.
I wonder if I can go dig up a datasheet somewhere.
EDIT2: None of the technical material talks about any frequency of the bulb, but you might be right. There's one other thing power-control thing that you can stick in a bulb that might take up space, and that's a dimmable power supply. Like, if the wall power voltage drops, those will detect and reduce brightness. This one's non-dimmable. Maybe that's where the bulge at the base of LED bulbs comes from
dimmer electronics
and there's enough space to fit non-dimmable electronics up inside the body of the bulb.
EDIT3: No, it's not dimmability that determines the bulge. I see corncob lights with no bulge that are dimmable and corncob lights with a bulge that are not dimmable. But that also invalidates my reasoning above -- you have to have power regulation circuitry to make dimmable LED lights work, because that requires a variable-PWM source, and if it's possible to build dimmable bulbs with no bulge at the base, then I can't assume that no bulge means that LED bulbs are being driven straight off wall power without power regulation, which was my original assumption. Sorry, this is probably my error then. These are probably being driven by an electronic ballast at some frequency higher than 60 Hz, just still low enough to be within the range that I can still see.
If you're in the EU, you probably retain an obligation to keep Russia from annexing Hungary even if Hungary were to hypothetically leave the EU, since there are also obligations to Hungary via NATO.
Aside from possibly Ireland and Austria, which have declared neutrality
and there are some disparate interpretations as to how this impacts EU mutual aid clause obligations
EU members are obliged to defend each other:
https://www.eeas.europa.eu/eeas/article-427-teu-eus-mutual-assistance-clause_en
NATO members are as well:
https://www.nato.int/cps/en/natohq/official_texts_17120.htm
These are not precisely the same obligations. For example, NATO does not oblige other members to defend metropolitan France in the Pacific, whereas the EU mutual assistance clause does. The EU mutual assistance clause does not oblige other members to defend their vessels against attack in the Mediterranean or Atlantic, while NATO does. But there's enough overlap that I'd expect Russia rolling into Hungary to trigger both.
EDIT: I'd also add that there is no mechanism to expel a member from NATO without them choosing to leave; probably the closest you could come would be to have all other members leave and then form NATO 2.0. There is also no mechanism to expel a member from the EU, but given the more-expansive scope of EU powers to impact member states, I imagine that the rest of the EU could probably de facto achieve the same thing by stripping a given members voting power (which is an option with otherwise-unanimous agreement) and then making their life sufficiently miserable using EU powers that they want to leave and choose to do so themselves.
My own view
and this is as an outsider, an American, so some of this doesn't affect me, in fairness
is that it wouldn't be a good move to try to eject Hungary. I remember some people on /r/Europe
well before Brexit
frustrated about the UK's position on some matter complaining that they wanted the UK out of the EU. I think that the reality of a member leaving is probably less-pleasant than the hypothetical. I think that when someone is frustrated, it is easy to see the negative points of membership, and easy to miss positives. Among other things, Hungary leaving would create a deep geographic split in the EU, cutting off most access among other EU member states in the area, like Romania-Slovakia. Just in general, it would impact the EU's scale. A Hungary outside the EU might prove to be more-problematic to remaining EU member states than a Hungary inside. Much of the upset seems to me to center around Viktor Orban; countries tend to outlive men and their time in power; and my belief is that the EU can probably afford to take a long-term view of things. I do not think that Hungary-under-Orban has represented any kind of existential threat to other EU member states; just an irritant on a number of matters.
I remember a while back, when the EU had the UK undergoing the Brexit procedure. Hungary and Poland were under separate Article 9 attempts to strip their voting powers. And then Macron, in some Franco-Italian dispute, called Italy a "rogue EU member". There were too many people trying to drive divisions and create fights then, I think. I don't think that moving back to that kind of situation would make the EU a better place.