My biggest annoyance with FastCGI is the ambiguity between FastCGI Server, FastCGI Application and FastCGI Proxy in documentation and articles.
To give some examples what I mean:
- Apache can be a FastCGI server (mod_fcgid) and proxy (mod_proxy_fcgi)
- Nginx (and most other Webservers I checked) is only a FastCGI proxy
Wikipedia [1] lists both as "Web servers that implement FastCGI". For me it took some time to recognize the difference whether a server speaks the FastCGI protocol or can also host/spawn FastCgi supporting applications which do not daemonize by themself.
For the (probably) most used FastCGI application PHP this is easy because php-fpm is both a FastCGI server and application.
An example for a (Fast)CGI application which is not also a server is MapServer [2] which is listed by Wikipedia as CGI program and by its own documentation with "FastCGI support" or "FastCGI-enabled".
The fact that it is only a FastCGI application and needs an additional FastCGI server to host it is (in my opinion) not clearly communicated.
A common tutorial to combine MapServer with Nginx is to use fcgiwrap or spawn-fcgi as FastCGI server.
Since a FastCGI application can usually also act as CGI application it is easy to miss that the first option is running the application as CGI and only the second as FastCGI where one instance serves more than one request.
For me the main difference is that a FastCGI server will open a socket and can spawn worker processes (which php-fpm does and MapServer does not) and a FastCGI application (the worker process) will accept and handle connections/requests.
A FastCGI proxy translates requests (usually from HTTP to FastCGI protocol) and redirects them to a FastCGI server. It does not spawn processes like Apaches mod_fcgid does.
Due to the simplicity it should be even possible to use systemd as simple FastCGI server. [3] (I have never tried it)
My recommendation if you ever come across an FastCGI application which cannot open a socket / daemonize by itself use Apache mod_fcgid. Even if you already use another Webserver to handle HTTP. From all options I checked it has by far the most useful options to dynamically limit the number of worker processes and respawn them from time to time.
Why wake up if your condition is not yet met? The wait timeout is the time after it should continue if it was not notified. It is meant to be waken up as soon as possible by a notify. If the value is available almost immediately it will wake up almost immediately whether it is wait(1000) or wait(5000).
Now the browser needs to define and document some kind of priority to solve those situations.
If you can have only one target anyway why not simply give special targets special values.
I'm late to the party but want to add that "reference date 1875-05-20 defaults to 150 years" explanation makes no sense to me.
Assuming the reference date is correct and unknown birth date is stored as timestamp 0. Since we are before 2025-05-20 at the moment the reported age has to be 149 years, not 150.
What I'm missing? Would be very unusual to round up age.
In short, in at least one variation, the attacker is able to smuggle in a known (unauthenticated) session token into the victims browser. Once the victim logs in the session token is authenticated and known to the attacker.
The easy countermeasure is to renew the session token on login and not reuse a previously unauthenticated session token. Or your application has no session at all before login.
> Java doesn't even allow to change the working directory also due to potential multi-threading problems.
Linux and macOS both support per-thread working directory, although sadly through incompatible APIs.
Also, AFAIK, the Linux API can't restore the link between the process CWD and thread CWD once broken – you can change your thread's CWD back to the process CWD, but that thread won't pick up any future changes to the process CWD. By contrast, macOS has an API call to restore that link.
That would be so much wasted engineering effort. The actual solution is simple: read what you need from env, and pass it as parameters to the functions you want to. The values of what you have read can be changed... and if you really, really want start a child process with a modified env.
Great, a few more decades and it might become a usable bugtracker.
What's next on the list? Maybe priority/severity or status/resolution?
I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.
I think 99% of the problems with Jira stem from trying to use it for too many things at the same time.
If it's used for tracking issues, it's great.
If a team just uses it for keeping track of its ongoing work, it ok.
If the team also uses it to plan work, it works less well.
If management also uses it to keep track of what the team is doing, it works even less well, because now the team needs to put on a show for management with the tool it needs to track and plan its work. Now issues need to be phrased in a way so that they aren't causing outsiders to worry. Maybe don't say "problem" or "bug" so often. Use an euphemism. Can't we word it in a less concerning way?
If upper management has a dashboard of all departments' boards, you get nested Potemkin villages where the jira tasks are performative for both middle management, who in turn try to dress things up even more for upper management. At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
> At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
This. In my case, it was the whiteboard. It was at a place I worked ~decade ago, where everyone was using Jira for the official work management. That included management, but also included everyone in the electronics production and assembly branch of the company, so it was funny to compare our meticulously described sprint items with co-workers burning through dozens of entries a day, named by just long incrementing numbers.
I believe Apple silicon has Jira coprocessor. It really became usable on M1 and beyond. Even the horrid UX got somehow better in the last few years (like not having 3+ different text inputs, each with different formatting behavior). My guess is since the hardware caught up with them they can now finally use it and iterate.
You jest, but I tested this and it turns out that it was JavaScript, not slow networking, that made Jira so slow for me. (I was trying to figure out how to locally cache assets to speed it up.)
The M-series single-core speeds were so much faster than Intel at the time that it was noticeably faster.
I don't have practical experience with JIRA Cloud Operations, or JIRA on-prem operations, but if I compare on-prem vs SaaS of our own solutions, the answer is scale and focus.
If I combine our three internal ticketing systems, we end up with something like 200k - 300k tickets, with maybe up to 5M comments on those in JIRA-Terms. If you throw a small-ish, decently configured postgres with 8GB - 16GB of memory at it, it'll keep most to all of that in memory at all times, indexes will be analyzed and fine-tuned to your specific dataset. It will answer queries very, very fast. Any cache in the application servers will also be primed with your data 24/7, speeding it up even further.
JIRA Cloud is most likely not an in-memory problem as a whole at a database layer, so it is at quite the disadvantage performance wise for a small customer.
(In case this turns into a SaaS-Hate-Thread: Yes our customers could have a faster system if they were on-prem. If they had the same experience and expertise running postgres as well as all the other necessary middlewares. And then we're not talking about non-functional operational requirements such as availability, emergency scalability or backups yet)
My guess is that self-hosted versions have an infinitely simpler user experience when it comes to accounts and visibility. Jira Cloud is definitely angled towards always being behind some sort of an account system, which used a real, costly backend, but the self-hosted one can get by with the local hosted IdP or an LDAP server.
Totally off topic, but Tags can be moved too. ;)
It's mostly a convention that we use annotated tags (a tag that also creates a commit) and don't move them
Transitioned from Jira to Gitlab. Jira has workflows/resolution states. Gitlab only has tags.
It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).
Using Github issues as a manager of multiple teams using multiple repos in GitHub has so many gaps, I often wonder if I'm just doing it wrong. The multi-repo issues feature a few years back was a huge step forward but also is very incomplete, still. Multi-repo labels and milestones, for example, are an obvious missing feature.
I really feel like GH needs to spin out Projects into a more dedicated, funded team while still maintaining a close sync in order for it to become more viable/interesting. Besides allowing it to grow faster and better, that should also allow for non-dev seat pricing.
IDK, but maybe, for the sake of people working in projects that are managed using Github/Gitlab issues, they'll spin off a separate "Tasks" features and allow to set dependencies on them.
Yeah I have no confidences in GH to become viable for issue management for large commercial projects.
It works fine if you're a group of highly competent and aligned FOSS developers that need it more as a communication tool than a work management tool. But if you get to breaking work down to the level of a few story points it becomes completely unmanageable. The table view turns into a slog if you have more than like 70 tickets.
In my opinion it should remain a shell thing. Adding tilde expansion just complicates the implementation of the tool. Now you need to know the current users home directory.
And some tools might implement it incomplete so that '~' works but '~name' does not work.
In POSIX shells '~name' expands to the home directory of user 'name'
$ echo ~bin
/bin
Now your tool need a way to query home directory for any user including system users. Depending on NSS configuration this is more complicated than just reading /etc/passwd.
All for the rare case that someone passes a file path starting with tilde and wants it to be expanded. IMO, when you provide a file interactively you do so through a shell and tilde expansion is handled by the shell and otherwise just provide the actual file path and do not rely on the tool doing additional expansions.
PS: I mixed up TUI and CLI program a bit in my head. For an interactively used TUI program it might be beneficial to implement tilde expansion (but then it should be as complete as in Shells). A CLI program should not do magic stuff like tilde expansion.
I remember reading some rant about how Unix sucks because of the shell's filename expansion, because programs can't tell whether you wrote a star or actually just all the files in the directory. If programs could tell the difference, then you could get the desired renaming behavior from mv like this:
mv *.m *.c
They suggested that this filename expansion should be in the C standard library, not the shell.
Going further, as part of shell expansion, expanding the tilde could also be useful for filename expansion in the standard library.
> And regardless of how you feel about the default the way they went about it broke things for users
For users using Debian unstable and even there it was apparently fixed/improved after a week.
Debian stable users had no "wild ride" and for the future became the choice to select between the full featured keepassxc version and a minimal variant without non-essential network and IPC features.
> [ERROR] No goals have been specified for this build.
> [ERROR] Unknown lifecycle phase "build".
And somehow missed that the error message also lists the valid lifecycle phases. (could have instead complained that it list all lifecycle phases which is a lot)
> // me searching on google how to not run tests
How do I know for other build tools how to skip tests? Skipping tests should not be necessary and is done to regularly. I would not consider a tool which immediately points out how to ignore those stupid tests as good UX.
When I want to run tests, I tell it to run the tests. When I want to install, I tell it to install. I don’t want it to run tests when I tell it to install. I don’t want tools who know better what I want to do than me.
To give some examples what I mean:
- Apache can be a FastCGI server (mod_fcgid) and proxy (mod_proxy_fcgi) - Nginx (and most other Webservers I checked) is only a FastCGI proxy
Wikipedia [1] lists both as "Web servers that implement FastCGI". For me it took some time to recognize the difference whether a server speaks the FastCGI protocol or can also host/spawn FastCgi supporting applications which do not daemonize by themself.
For the (probably) most used FastCGI application PHP this is easy because php-fpm is both a FastCGI server and application.
An example for a (Fast)CGI application which is not also a server is MapServer [2] which is listed by Wikipedia as CGI program and by its own documentation with "FastCGI support" or "FastCGI-enabled".
The fact that it is only a FastCGI application and needs an additional FastCGI server to host it is (in my opinion) not clearly communicated.
A common tutorial to combine MapServer with Nginx is to use fcgiwrap or spawn-fcgi as FastCGI server.
Since a FastCGI application can usually also act as CGI application it is easy to miss that the first option is running the application as CGI and only the second as FastCGI where one instance serves more than one request.
For me the main difference is that a FastCGI server will open a socket and can spawn worker processes (which php-fpm does and MapServer does not) and a FastCGI application (the worker process) will accept and handle connections/requests.
A FastCGI proxy translates requests (usually from HTTP to FastCGI protocol) and redirects them to a FastCGI server. It does not spawn processes like Apaches mod_fcgid does.
Due to the simplicity it should be even possible to use systemd as simple FastCGI server. [3] (I have never tried it)
My recommendation if you ever come across an FastCGI application which cannot open a socket / daemonize by itself use Apache mod_fcgid. Even if you already use another Webserver to handle HTTP. From all options I checked it has by far the most useful options to dynamically limit the number of worker processes and respawn them from time to time.
[1] https://en.wikipedia.org/wiki/FastCGI [2] https://en.wikipedia.org/wiki/MapServer [3] https://nileshgr.com/2016/07/09/systemd-fastcgi-multiple-pro...