I haven't used Fiverr but I have recruited on craiglist and in-person for what I would call a 'social media editor' and never wound up happy with the work I was getting and what I was paying for it.
In my mind a writer like that has to write "a lot" of articles (e.g. a lot of words total, but not many per articles) and be expected to reach a certain levels of quality, but not to do the amount of work that somebody might put into some things. I felt like I could reach that standard myself but couldn't really get others to go there -- some people had no standard for quality at all, others wanted an hourly rate I couldn't afford for what they produced and thought my piecework rate was too low. Maybe half of it was intrinsic to the situation, maybe half of it was my not being good at hiring/managing and not trying for longer.
I know about them. But I would have to root my phone to install them. And that means trusting some binary blob from someone on the internet. So I would not do it.
On iOS maybe, but there's no problem installing 3rd party app stores on Android without rooting. See for example F-Droid.
Recent versions of Android have also improved the permissions model... you can specify what apps (e.g. F-Droid) are allowed to install other apps. You don't need to add a blanket allow forever.
some of the function names make
me want to stab people
What would be an example?
My only real gripe with PHP is
the annotation syntax
What do you mean? Afaik there is no "annotation syntax" in PHP. Could it be that you confuse what certain frameworks and IDEs do with PHP, the language?
I have heard—and I do not recall the source for this, so it may be incorrect—that when PHP was originally being written, the hashing algorithm for function calls used the length of the function name as its primary key. Thus, making each function name a slightly different length made the code run faster.
Of course it would've been nice if, at any time in the past 20 years, they'd gone back and standardized those function names (possibly also adding some kind of backwards-compatibility shim for people who absolutely cannot update their ancient codebase with global search-and-replace), regardless of whether the story is true.
Second third to the reason is that PHP often takes names from underlying C libraries. strlen is strlen since that's the C name etc.
Third third reasoning is that early PHPade it easy to contribute. You had a need and a patch - a few minute Slater it is in. Nowadays there is more of a debate and vote before things are added (in my personal opinion too much emphasize on voting, but, well that's how things go, some day the process will be relaxed again ... and strengthend ... and relaxed)
Cleaning this up isn't trivial. There eis sooooo much code written already. There are sooo many tutorials, books, articles, magazines, videos and muscle memory making a change hard, even ignoring that for many things there is no single truth about what is best.
From time to time some modules might see replacements with more streamlined APIs (i.e. Maybe someday one figures out what a good and practical Unicode aware string library might be, which might replace the classic string mess) but those are multi year things.
A good place to start would seem to be creating naive aliases to these functions to at least fix the consistency problem. There's a possibility of breaking some code out there if someone made their own, say, "str_cmp", but we're used to breaking changes between major revs, and these could be fixed with a grep -l | xargs sed.
After that's done, we can talk about deprecation warnings, and then finally outright removal.
Doing that means you have to first agree on a name, strcmp has vertical consistency with C. str_compare might be nice, string_compare even nicer.
Once that debate is over you have to migrate all old code and all developers and teach them to use the new form. Throwing away all preexisting documentation and telling them why typing more is better.
Only then the old form can be removed.
Is it really worth it? - And yes, there is an argument "in the next 25 years there will be noore code written than in last 25" but still, is it worth it?
To give a feeling on the time period: PHP had this register_globals feature where URL (GET) and POST parameters became global variables. Getting rid of that, from introducing a replacement, over changing default and final removal of the option, too 10 years. When taking that time frame it's 10 years of confusion.
Problem 1 is basic standardization and naming things. Hard, but possible.
Problem 2 is is solved by adding the deprecation warnings. The code works, but it generates warning messages.
Yes, it'll take some time, but I'd argue it's necessary. Unless you've memorized the entire standard library, remembering which functions use underscores and which don't (and which ones use "to" vs "2") is an unnecessary mental burden.
Not to mention array_reverse (or is it reverse_array, I forget) which returns a new array leaving the original intact, whereas the sort functions return 1 and operate on the original array in place.
Also, why is it array_reverse, but rsort? I dunno.
The mix of c like strpos, strstr and inconsistent parameter ordering (see array map and filter for example)
> What do you mean? Afaik there is no "annotation syntax" in PHP. Could it be that you confuse what certain frameworks and IDEs do with PHP, the language
If there's no official standard, but everyone follows a community standard, then that is the standard. Quit being pedantic.
Hopefully PHP 8's attributes work to fix the mess that is phpdoc being used for annotations.
There's possibly an argument that reusing C names when you're wrapping or emulating C functions is actually a good usability design choice which has, over time, become a negative.
Like a floppy-disk save icon, what helped one generation becomes obscure to the next and they obly see the flaws.
When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup.
I do not want to write a "service" that has some "only run once and then discard" flag or whatever.
When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.
When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
Heck I hadnt used Linux for a few years and when I got back to it systemd was on every distro I use. I just use it. I dont see the big deal. I grep the piped output of services if I want to narrow things down more just as you would the output of cat or ls or anything on Linux.
But there have been reasons given. They want to use standard tools to deal with the log. They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.
> They want to use standard tools to deal with the log.
I have a little sympathy for this one as an old habit if you don't know any better. It's also an extremely inefficient way to work with logs. If you've used a system like Splunk seriously, the idea of going back and grepping through logs on a host with the shell is just frustrating.
> They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.
I have no sympathy for this one. Scripts are a terrible place to define policy. They are nigh impossible to audit. They are brittle. They multiply complexity by making everything a special case. They make integration of different parts of the system nearly impossible.
Aren't systemd units simple text files with no hidden magic? In fact, all systemd configuration is plain text files and symbolic links. The only binary format is the journal.
> Aren't systemd units simple text files with no hidden magic?
Compared to something like a shell script, systemd unit files are magic because you have to know a lot about how systemd works to figure out how your config file translates into actual behavior.
Whenever systemd comes up, someone appears to counter any criticism with words suggesting you'll get left behind if you don't follow us. No justification beyond that.
> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup
This is not very specific, have you never had any race-condition with this? There is a reason SystemD ask some informations regarding the service that needs to be launched. I don't see how ignoring those makes a good argument against SystemD.
They mean that you can specify dependencies. So start some service Y only after X has been started. I use this extensively in my home automation services. Can't start other services if the MQTT-Server hasn't started and that isn't done until the network is initialized.
Hardly. I'm an OpenRC user. Booting OpenRC vs SystemD, desktop, server, VM. Near zero difference in boot time, neither side was a clear winner, nor always faster.
My favorite part is OpenRC still likes the old ways, has script extensions for new ways, and runs the same path every time.
That's just anecdotal. If it's a technical fact that SystemD does parallel upstarts where OpenRC for example does not, that just means you don't have a system where parallel upstart makes a difference.
I think my issue what binding Consul to docker0 while Docker is starting. Half the time the interface wasn't ready. I don't remember exactly how I fixed it but with SystemD you can just specify a dependency.
> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup.
AFAIK, systemd is compatible with sysv init scripts.
> I do not want to write a "service" that has some "only run once and then discard" flag or whatever.
Why? Writing one isn't so complicated.
> When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.
Well, nothing prevents you from piping output from journalctl to whichever tool you prefer. In fact, people do it all the time.
> When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
I don't see how sysv init is any better than systemd in this regard. You'd still have to look at indidual scripts to see what it does. It's not like systemd hides the contents of the service files.
> A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
Interesting. I feel the other way. Unix failed to provide a real service management system early on, so we have layers of historical cruft (Fork, close all descriptors, fork again, escape process group? Really?), and ended up with all kinds of absurdity in shell scripts to handle it.
The right way is to have a strong system contract on what constitutes a service, and have no wiggle room so that 'service apache start' does a fixed, known thing.
Sadly, systemd has to support all kinds of legacy hacks. A nice way to chart a way forward might be to define a simple contract and require someone to mark a unit file as "legacy" to enable the other possibilities.
So I take it you've never used journalctl then at all? Because seeing as how it's default behaviour is to use the system pager, which on any system with `less` installed is less, I'm somewhat at a loss as to what you can't do with it that you can with files now.
Can these people really do something useful for a startup?