The Flat Earth Society
Other Discussion Boards => Technology & Information => Topic started by: xasop on January 30, 2015, 12:41:30 PM
-
I've decided to get serious about contributing to an open-source project. In the past, I've submitted patches here and there, but never seriously taken the time to contribute regularly. That's going to change.
Starting this Sunday, I'm going to spend three hours every Sunday afternoon (from 14:00 to 17:00) working on OpenBSD. The first hour (14:00 to 15:00) is reserved for working on and submitting fixes to problems I know I am capable of fixing. I might spend over an hour on that, but an hour is the reserved minimum, unless I fix all such problems beforehand.
The remaining time will be spent learning about things that interest me. This includes things such as reading source code, debugging complex issues, and testing experimental code from the mailing lists. The intent is that I'll probably be interested enough most weeks to continue working on this after the time allocation. There's lots of stuff I want to do, but I keep forgetting about it and then remembering at odd moments when I don't have the time for it.
I'm going to post what I'm working on here, because if I don't post it somewhere others can read it, I'll forget and/or give up easily. If you aren't interested, just don't read this thread.
Sunday, 1 February, 2015
Problems to fix (in no particular order)
- Submit patch against the net/pidgin port to make nick colours in MUCs deterministic. I've been using this patch for a few weeks at the office, so I know it works well, I just need to send it to the developers.
- Fix a typo in pfsync(4) I happened to notice.
General learning (in order of decreasing interest)
- Read through the sndio(7) audio subsystem source code, and understand how it fits together. Exercise: Try writing a headphone crossfeed DSP for sndio.
- Read the USB 2.0 specification and try to implement transaction translator support in uhci(4).
- Write a port for xpra (http://xpra.org/).
- Read and try to understand the inteldrm(4) video driver, as a prelude to debugging an issue with my dual-head configuration at the office.
- Try to implement virtual consoles in the console driver for the Lemote Yeeloong.
I might add more stuff later, as I think of it.
-
Is the goal to make it as good as Lunix?
-
Is the goal to make it as good as Lunix?
You can run Linux applications on BSD at native speed, so it is arguably already better than Linux if that is what you want to use as your criteria.
If I had to guess, it seems Parsifal is trying to learn as much as he can as well as give back to the community that has benefited him for so long.
-
If I had to guess, it seems Parsifal is trying to learn as much as he can as well as give back to the community that has benefited him for so long.
I've already given back from time to time, as I said. This is mainly about becoming more intimately familiar with a specific project so I can start making larger contributions, and OpenBSD is a project I'd like to get more familiar with. And of course, learning is always an important part of anything I do.
There is also the possibility of starting a business based around OpenBSD. I'm not quite sure what I'd like to do yet, but it would be cool to sell and support appliances running OpenBSD, mainly because of how fucking terrible most embedded systems are. I feel I could really make a difference there.
An example of a successful business based on OpenBSD would be M:Tier (http://mtier.org/), which provides binary packages for stable releases (only released by the OpenBSD team in the form of source patches), among other services.
-
What makes OpenBSD preferable to Linux?
-
What makes OpenBSD preferable to Linux?
A lot of different reasons, which mostly come down to a difference in development and licensing philosophies.
Linux developers like to reinvent the wheel time and time again, making different mistakes each time; OpenBSD usually holds off on implementing new features until they know they have a design that is likely to work well. It's not something you notice if you use Linux casually, but having used it as my primary OS for the past six years, it's become very apparent over time. OpenBSD has remained relatively steady, with fewer total changes but a greater overall improvement.
OpenBSD also favours simple solutions to problems, with only as many knobs exposed to the user as are actually necessary (and very complete documentation of all such knobs), resulting in a smaller codebase that runs well even on very old hardware. Contrast this with Linux's (and GNU's) approach of making software that can be anything to anyone, and is so configurable that it becomes a nightmare to support, with almost every feature being underdocumented.
Finally, OpenBSD has a very strict liberal licensing policy (http://www.openbsd.org/policy.html). They are not accepting any new GPL'd code into the system, although some parts (like the compiler) are under the GPL because there is currently no viable alternative. In short, their policy is that their software should be usable by anyone for any purpose, with as few restrictions as international copyright law permits, which makes it very easy to comply with their licensing terms. Contrast this with the greedy tentacles of legalese in the GPLv3 (https://gnu.org/licenses/gpl.html), which aims to use copyright law to influence patent law, among other things. A complex licence is more difficult to comply with, and that can be a large deterrent for commercial use. While Linux itself is not licensed under the GPLv3 (it uses the older GPLv2, which is still complex, but less so), many of the GNU userland tools most often found on Linux systems are.
Those are a few of the biggest reasons I'm making the switch from Linux to OpenBSD, and I've come to recognise them simply by observing the problems they cause in the real world when running Linux. I don't have examples handy, so it's difficult to substantiate them, but they are my personal experience.
Edit: Linux and GNU are actually both based on AT&T's System V from the 1980s, which has a similarly questionable history of poorly reinventing things (its init being a good example, having been reimplemented as a GNU project, and now being replaced with something just as bad in most Linux distros). OpenBSD is based on BSD, which forked from AT&T's UNIX in 1979, and (aside from having System V interfaces added in the late '80s for POSIX compatibility) has generally followed a much simpler approach to software development. For contrast, OpenBSD's init (http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/init/init.c?rev=1.52&content-type=text/x-cvsweb-markup) is an open-source reimplementation of the original UNIX init model.
I mention this mainly to illustrate that the difference in philosophy goes back farther than the Linux and OpenBSD projects, and that it is almost as old as UNIX itself.
-
Well, I'm off to a great start. Didn't wake up until after 15:00 today.
I'll do this anyway, just from 16:00 to 19:00 instead.
-
Well, that was a bumpy first session. I took the time to subscribe to a lot of OpenBSD mailing lists (I had previously only been subscribed to three), and to upgrade OpenBSD on my laptop. Then, about halfway through, my laptop's transformer overheated and blew, sending me onto battery power. Fortunately, I had a spare.
Anyway, these are now done:
Problems to fix (in no particular order)
- Submit patch against the net/pidgin port to make nick colours in MUCs deterministic. I've been using this patch for a few weeks at the office, so I know it works well, I just need to send it to the developers.
- Fix a typo in pfsync(4) I happened to notice.
I'm not really in a learning kind of mood after all that, so I'll defer the rest until next week. At least I got the simple things out of the way, and I'm all set up to proceed without as much fucking around next week.
Later tonight, I'm going to watch Apocalypse Now. I haven't seen it before, but it's the theme for the most recent OpenBSD release, so hopefully I'll get more of the jokes in the release artwork after watching it.
-
Sunday, 8 February, 2015
Problems to fix (in no particular order)
None. I already fixed the outstanding problems last week, and didn't get around to any of the general learning exercises.
General learning (in order of decreasing interest)
Carried over from last week:
- Read through the sndio(7) audio subsystem source code, and understand how it fits together. Exercise: Try writing a headphone crossfeed DSP for sndio.
- Read the USB 2.0 specification and try to implement transaction translator support in uhci(4).
- Write a port for xpra (http://xpra.org/).
- Read and try to understand the inteldrm(4) video driver, as a prelude to debugging an issue with my dual-head configuration at the office.
- Try to implement virtual consoles in the console driver for the Lemote Yeeloong.
New stuff I've thought of:
- Read through the Linux binary emulation layer, and try to make it work on amd64.
-
- Read through the sndio(7) audio subsystem source code, and understand how it fits together. Exercise: Try writing a headphone crossfeed DSP for sndio.
Decided to have a poke at this. Turns out the sndio framework has changed a lot since this paper (http://www.openbsd.org/papers/asiabsdcon2010_sndio.pdf) was published; they've adopted a simpler but less flexible architecture, so writing a DSP is going to be more challenging.
-
Decided to have a poke at this. Turns out the sndio framework has changed a lot since this paper (http://www.openbsd.org/papers/asiabsdcon2010_sndio.pdf) was published; they've adopted a simpler but less flexible architecture, so writing a DSP is going to be more challenging.
So much for Mr Cynical. An hour later, and I have a hacky but functional prototype. I rule.
-
This is going to have to be deferred until later, as I need to stock up on my medication this afternoon.
-
Sunday, 22 February, 2015
Problems to fix (in no particular order)
- Determine whether I have sufficient information, and if so, file a bug report for my Intel graphics problem at the office.
- Send a patch for the website to make statements on the GPL's acceptability consistent.
- Send a patch for the website to clarify that machdep.allowaperture is not needed with KMS.
- Read through the FUSE code, fix some minor issues I noticed and see if there are any others. I'll probably defer this one until after the 5.7 release, but I just wanted to put it down so I don't forget.
General learning (in order of decreasing interest)
Carried over from last week:
- Continue playing with sndio(7), and try to make my bs2b plugin better. Perhaps ask on the mailing lists for pointers on what kind of changes would be accepted.
- Read the USB 2.0 specification and try to implement transaction translator support in uhci(4).
- Write a port for xpra (http://xpra.org/).
- Try to implement virtual consoles in the console driver for the Lemote Yeeloong.
- Read through the Linux binary emulation layer, and try to make it work on amd64.
-
This week is a bit special. I am going to troubleshoot why my window manager (i3 (http://i3wm.org/)) isn't correctly picking up my Mod keystrokes on my new iBook, so I can begin using X seriously.
-
This week is a bit special. I am going to troubleshoot why my window manager (i3 (http://i3wm.org/)) isn't correctly picking up my Mod keystrokes on my new iBook, so I can begin using X seriously.
Successful afternoon is successful:
https://github.com/i3/i3/pull/1504
-
Now that I've installed OpenBSD on my primary workstation, it's time to get this started again.
This weekend, I intend to keep working on my Perl bindings for libsndio (https://github.com/stevenjm/perl-Audio-Sndio), as well as trying to write a port. Things I'd like to write ports for include:
- Ardour 3
- bash-completion
- daemontools
- xpra
- various libraries I rely on for scripts and what not
I'm sure I'll think of more as time goes on.
-
Now that I've installed OpenBSD on my primary workstation, it's time to get this started again.
This weekend, I intend to keep working on my Perl bindings for libsndio (https://github.com/stevenjm/perl-Audio-Sndio), as well as trying to write a port. Things I'd like to write ports for include:
- Ardour 3
- bash-completion
- daemontools
- xpra
- various libraries I rely on for scripts and what not
I'm sure I'll think of more as time goes on.
Add "dirvish and its perl dependencies".
-
I got an xpra port partially written, and improved my bs2b crossfeed feature in sndiod (still not ready for sending upstream, though).
-
Apparently nothing got done this week...
-
Apparently nothing got done this week...
Actually, I've started learning Rust, in the process of which I got Cargo (Rust's package manager) to build on OpenBSD. I've already submitted one patch to the cargo-bootstrap project, with more on the way once I figure out the correct fixes to the problems I hacked around.
-
Apparently too busy to update >:(
-
Apparently too busy to update >:(
-
Yeah, I was enthralled by your updates ;_;
-
Why no talk about BSD? Is it because you now Lunix?
-
2017 has been a dope year of updates so far.
-
I've been kind of busy moving from one side of the Earth to the other.
-
I've been kind of busy moving from one side of the Earth to the other.
Ah, I didn't realize you've been traveling by sailboat these past 8 months. My apologies, carry on.
-
Parsifal has taken the Star Citizen approach to development progress.
-
Parsifal has taken the Star Citizen approach to development progress.
But he's not demanding money.
So wouldn't it be the Valve approach? Silence so no one realizes you're not doing anything?
-
Parsifal has taken the Star Citizen approach to development progress.
Almost as if I'm a student now...
-
Parsifal has taken the Star Citizen approach to development progress.
Almost as if I'm a student now...
Sorry, I forgot about that. I can see how becoming a student a week ago would delay progress for the previous four years.