2023-07-13
+ +Alright, just a short blog post for today. I am NOT an open source enthusiast. +Every time someone calls me a "open source" enthusiast, I want to shoot someone. +I do not support the open source movement and I do not support open source +software, or as a lot of people will say "FOSS".
+ +The goal of open source is to provide the source code for ease of collaboration +and for vulnerabilities to be discovered. Big companies can then take that project, +which is almost always licenced under a cuck license, +and release it in the form of nonfree software with additional spyware added on. +The most notable example of this is the Google Chrome web browser, where Chromium +is the "open source" variant of the software, only without the spyware and with +the freedom to modify and distribute copies of the software.
+ +The goal of free/libre software on the other hand is freedom for all users of the +software. These are:
+ +While free software is often copyleft, meaning you cannot fork the project +and relicense it under a nonfree license, stripping away the freedom from +the users of that fork, free software is not always copyleft. Therefore +open source software is almost always compatible with free software. If you +are using open source software you are most likely using free software.
+ +Open source software that meets the free software freedom criteria is just +as ethical as free software. The main problem is you're sending the wrong +message to people. But the software is still free as in freedom.
+ +To be clear, I do believe nonfree software (software that doesn't meet the +four essential freedoms) is unethical. But I do not dislike anyone for using +nonfree software. It's kind of difficult to avoid using nonfree software in +this day and age. Respect to those who are able to use 100% free software +(going as far as using a libre kernel and free BIOS) though.
+ +You are not unethical for using nonfree software. The unethical practice +is actually licensing that software under a nonfree license and releasing +the software to people.
+ +A lot of people will say "what's the difference" or "who cares" when I +mention I don't care for open source software. The reason it matters +is because when you talk to people who may or may not care about freedom, +you should be telling them that you care about freedom, not price.
+ +FOSS stands for "Free and Open Source software" but I cannot stand this term, +because it implies that the software is open source and free as in price, +meaning you don't have to pay any money for it. Most people when they hear +this term, both tech enthusiasts and normies think it means you get it for +free. This is the problem. The message we should send is that the software +is free as in freedom, not that it doesn't cost any money.
+ +I am not for the open source movement. I do not support open source software +for the sake of collaboration or for security vulnerabilities to be discovered. +I support free software because free software respects users' four essential +freedoms. Everything open source provides free software also provides. +The main difference is the goal of the movement. I do not care for the +open source movement and their motives. I care about the FSF's definition +of free software and freedom for all users.
+ +The reason "open source" is more popular now is because it's more corporate- +friendly. Companies do not care about your freedom, but they certainly do +care about unpaid work and security audits. Companies are against free +software because they are against user freedom.
+ +That's it for today. Have a good rest of your day!
+ + ]]> +2023-07-08
+ +You may or may not be aware of it, but I started designing a package manager
+back called packr early March this year. It was pretty poorly designed
+however, and I don't think I had goals properly planned out. So I'm going to
+talk about some of the goals I have in this blog post.
Of course, they are subject to change, because I haven't implemented anything +yet. You can always watch the development +happen at the packr Git repository.
+ +If you have any suggestions on improvements, or think something I mentioned here +is stupid or unrealistic, please let me know. I am always open to suggestions +and potential improvements, no matter how ridiculous they may be.
+ +While I do plan on finishing this package manager and making it a reality, I'm +not sure when. Either way, what is listed here is going to document how I'm going +about designing it.
+ +You may ask, why design a new package manager? Well, I'm going to compare packr +ideas to existing package managers, but I don't like the design philosophy of +most package managers, and I also don't like the state of modern GNU/Linux.
+ +One of the first key features I want to mention is that packr is going to be a +source and binary hybrid. That means both binaries and source based packages will +be available.
+ +pacman's main flaw is being based around binary packaging, and the finished packages +don't handle compilation whatsoever. This means the user cannot compile packages +himself without grabbing a PKGBUILD which will generate a binary package anyway.
+ +Portage fails here too. Portage is an excellent source based package manager, and +it is designed around source based packaging. It is definitely NOT designed for +binary packages though, and while it can be done it doesn't feel quite right.
+ +packr should install packages the same way, whether you're compiling a package
+or installing a package someone else compiled for you. packr -i firefox should
+install Firefox, regardless if it's a prebuilt binary or source code. This is going
+to be achieved by having multiple versions in the repository at all times. Source
+based packaging is going to be the primary packaging, and users (or maintainers)
+will be able to submit prebuilt binaries in addition to those source based packages.
As I said, source based packaging is the primary way to handle packaging in the +repositories. However, because binary packaging is lacking on source based +distributions, I plan on solving this by allowing all source based packages +to be automatically compiled into a binary package after it has been installed +and compiled once.
+ +In practice, if one user compiles Chromium 113 from source, that user can generate +a Chromium 113 binary package using packr itself in seconds, and submit this +to the repository in addition to the Chromium 113 source package.
+ +Any user can submit source packages to a repository, and then other users can +fill the void by submitting a binary package based on that source package. Or, +of course a source and binary package could be submitted at the same time.
+ +Packages should be POSIX shell script based. POSIX shell is a scripting language +everyone who uses UNIX like operating systems are eventually forced to learn. +Therefore, using this for packages is a great way to make packages as easy to write +as possible.
+ +If I end up writing it in C, one idea I have in mind is to have a shell script +read the package and send instructions to the main packr binary. This means the +only limitation is the shell itself. Either way, the packaging will be shell +script based. packr should be built around this fact.
+ +If I end up writing it in shell script, it would probably be even more extensible, +but perhaps a bit slower. It must still be faster than Portage.
+ +No, this is not about the FSF or free software. Packr packages should specify +if they make network requests, if they read files from the disk, if they need +superuser permission, programming language, dependencies, and so on. Think +Android. On Android the user is able to read what permissions the program +requires before installing it. That's an important part of packr packaging.
+ +Packages also need to specify licensing. This allows the user to make a decision +on whether or not he wants to use a software under the license. When a package is +installed, the user should (optionally) be notified of any antifeatures, the +aforementioned permissions such as network requests, and make a decision based on +that.
+ +If the user only wants to use GPL licensed software, he can. If the user +hates Richard Stallman and doesn't want to use anything GPL licensed, he can do +that too. If he wants to run Microsoft spyware and use a proprietary kernel, he +can do that too. The package manager should not prevent any of these things +unless the user wants it to.
+ +packr should be hackable and extensible. It should interact with other programs +and it should use existing programs where the existing solutions are good. +Don't reimplement packaging, or signing or repositories. Git should be used +for repositories, PGP signatures and checksums should be used for signing +packages, packages should be tarballs containing a shell script packr reads, +and for binary packages it should contain the main binaries too.
+ +