For a lot of things I would rather have something web based than app based. I hate having to download some random app from some random company just to interact with something one time. Why do all restaurants, car parking places etc require apps rather than just having a simple site. Not everything should be native first IMO.
nous
joined 2 years ago
If the package is popular then it is very likely already packaged by your distro. You should always go there first if you care that much. If the package is not popular enough to be packaged by a distro then how does another centralized approach help? Either it is fully curated like a distro package list and likely also wont contain some random small project, or it is open for anyone to upload scripts to so will become vulnerable to malicious scripts. Worst yet people would be able to upload scripts to projects they don't control as the developers of said project likely wont.
Basically it is not really any safer then separate dev owned websites if open nor offer better package support then distro repos if curated.
Maybe the server was hacked and the script was changed?
Same thing can happen to any system though. What happens if your servers for this service are hacked? Being a central point makes you a bigger target and with more people able to change (assuming you are not going to be the only one to curate packages) things you have a bigger area of attack. And once hacked they can compromise far more downloads than a single package.
Your solution does not improve security - just shuffles it around a bit. Sounds nice on paper but when you look at it in more details there are a lot more things you need to consider to create an actually secure system that is better then what we currently have.
Then how would you trust these scripts in a central repo? Seems to add no real value or safety over dev managed scripts if you are not willing to go down the path of becoming yet another distro packaging system.
There is also no way to verify that the software that is being installed is not going to do anything bad. If you trust the software then why not trust the installation scripts by the same authors? What would a third party location bring to improve security?
And generally what you are describing is a software repo, you know the one that comes with your distro.
Cannot remember if the study was stupid or if peoples interpretations of it where. But when covered up else where you will lose a lot of heat through your head. More so then if just an arm or just a leg was exposed as with your arms and legs your body will slow down blood flow through them to try and converse your core temperature - it cannot do that with your head.
once a developer enacts an end of life plan, their legal culpability is removed What legal culpability? If you are not hosting anything then you wont be liable for anything. It is not like if you create a painting and someone defaces it with something that you become liable for that... That would be insane.
Random programming certificates are generally worthless. The course to get them might teach you a lot and be worth while, but the certificate at the end is worthless. If it is free then it does not matter too much either way, might be a good way to test yourself. But I would not rely on it to get you a job at all. For that you need other ways to prove you can do the job - typically with the ability to talk about stuff and having written some real world like application. Which a course might help you do to.
The indicator being stuck is a recently fixed issue:
Fixed a case where the battery level indicator could become stuck
https://store.steampowered.com/news/app/1675200?emclan=103582791470414830&emgid=529850584204838038
YAML is not a good format for this. But any line based or steamable format would be good enough for log data like this. Really easy to parse with any language or even directly with shell scripts. No need to even know SQL, any text processing would work fine.
CSV would be fine. The big problem with the data as presented is it is a YAML list, so needs the whole file to be read into memory and decoded before you get and values out of it. Any line based encoding would be vastly better and allow line based processing to be done. CSV, json objects encoded into a single line, some other streaming binary format. Does not make much difference overall as long as it is line based or at least streamable.
Never said it had to be a text file. There are many binary serialization formats that could be used. But is a lot of situations the overhead you save is not worth the debugging effort of working with binary data. For something like this that is likely not going to be more then a GB or so, probably much less it really does not matter that much if you use binary or text formats. This is an export format that will likely just have one batch processing layer on. This type of thing is generally easiest for more people to work with in a plain text format. If you really need efficient querying of the data then it is trivial and quick to load it into a DB of your choice rather then being stuck with sqlite.
Yeah I don't like this either. So many chances for a mistake, be in the wrong dir, file misspelled, something not cloned correctly or anything else not setup as you think it might be and suddenly the package manage does something you don't expect (like try to install globally rather then in a project or vice versa).