I usually make do with `man` pages for C (very comprehensive), and the `python-docs` package in my distro (you can download a static copy of the python documentation, and even the search will work offline). As well as whatever PDF manuals I need for what I'm doing.
As I use Gentoo I also usually have the source code for anything on my system, so I can dig into that if I'm missing some docs, as there's frequently a docs/ folder in the archive.
If I'm missing documentation, I make a note of it and see if there's a way to make it available locally, somehow.
I used to commute 1h40m one way, which accounted for 50mins in a train (+10min avg waiting). While I ususally did pull out my laptop, the productivity just wasn't there - I can't consistently work while groggy/vitamin-d deficient during winter mornings, or in the evening being cooked after having worked for 8 hours (I have an office job, but not programming). The seats are cramped and uncomfortable, not being able to raise my arms enough to use the keyboard without bothering the passanger next to me, so I'd have to put it away during the crowded parts of the ride, and I'd be very frustrated if the train was unusually crowded. Having your "flow" be broken by arriving at the end stop and having to rush to pack your things is awful. The only conversation someone's struck up with me was a guy who insisted he'd never understand what I was doing even if he tried.
Suffice to say, after almost two years of this, I was extremely tired and sleep deprived as this ate away at my available time more than what is reasonable. Using the time for personal projects didn't compensate for it. Never again, it's really not worth it.
Started a comment to write basically what you said. I've been commuting like that for five years. At the end I didn't bother trying anything productive anymore.
Losing 2-3h per day commuting is not something I am gone miss anytime soon.
Of course not, but unlike chat services, everyone has an email address or phone number, so if I need to reach out to them for something other than a casual chat, e.g. an invitation, a birthday felicitation, or a document that they should review later, email is a method through which I can reach all of them.
Similarly, reaching out to companies for support also often happens over email.
This post is AI sludge and by the third bullet list I couldn't keep reading. This is stuff I deeply resonate with but jesus christ please respect my time and don't drown me in extremely verbose prose goop.
> makes it impossible for attackers to add new executable files to the system which stops almost all attack vectors
If you have code execution - any kind - you have code execution. It really doesn't matter if a shell is available or not, you're always an open(2), write(2), and execve(2) away from creating and invoking a new executable, or just mmap(2)ing a new executable region in the current process. Yes, most exploits leverage a shell because it's convenient, so you're making it a little bit more annoying by having to first write an executable, but it really doesn't stop attacks like this.
Much more effective measures are those that prevent program takeover in the first place (SSP, ASLR), and things like W^X.
been using this for years.. it doesn't have the GCM crap and hence works on de-googlified custom ROMs as well. Surprised how many people don't seem to know about it.
> Surprised how many people don't seem to know about it.
There are a few reasons for that.
1. The link to APK cannot be found on the official site[0], so it needs to be looked up in a search engine.
2. Even when downloading from the site, they try to scare you away with a warning [1]. The reason for warning could be avoided by hosting their own F-droid repo, but they refused it, claiming you can download APK and not listening to reason[2].
Though for people using F-droid can still get Signal through the Guardian repository [3]
Thing about the signal APK and the Guardian one is that, it still have the so called "crap" in the final APK, it just runs a background service when required google services are not detected, causing battery drain for many[4].
The drain could also be avoided by supporting UnifiedPush (it can fall back to FCM when it's detected), but they don't want to do that either[5].
> Surprised how many people don't seem to know about it.
I'm pretty sure people just want to be angry. I mean look at how many people are arguing that updating is... bad. I cannot and will not take those people seriously. It's just such a laughable position.
There's also a great feature with this too. If you don't update for long enough then my chats won't transmit to a vulnerable device, such as one that is running too old of a version. Now that's a great feature
I'm not sure why they're doing it; anyhow, I'd at least avoid doing the initial installation through that repo, you're trusting an additional party for no gain that I could think of (updates are ok because the signature needs to match the one of the installed version).
For some of us software freedom enthusiasts it is worth noting that PebbleOS contains some proprietary blobs for some peripherals in the watch[1]. This is not just firmware you upload to the peripheral but also properietary .a libraries that run on the main core.
Though to be fair to OpenDevices, this is source code they don't have acces to either.
I don't really know that this is avoidable without buckets of work and probably legal issues on behalf of core's (or anyone's) engineers- it's really just something that plagues hardware in general.
Hell, lots of sensors/etc these days are running fairly complicated software that's totally opaque.
Do you demand circuit schematics? Hardware description language source code for all the ICs? Does it matter if it’s a FPGA vs a custom IC? What about CAD files for the industrial design - some of that is ‘functional’ (camera lenses and antennas being obvious examples).
If you don’t require hardware description language source or circuit schematics, does your position change if it’s a microcontroller with firmware? The functionality could be outwardly identical to a fully ‘hardware’ IC or FPGA, down to pinout and timing (see, for example, the many projects ‘cloning’ obsolete and unavailable custom ICs with microcontrollers in the retrocomputing field).
The simple statement that it's not 100% open source is not an attack on the effort. It needs to be said, because the blog entry's title is "Pebble Watch Software Is Now 100% Open Source".
Incidentally, this is one reason why there's not so much open source hardware out there: people get pedantic about it and apply gradually more unreasonable levels of requirement, rather than accepting partially or substantially open source solutions.
I can be pedantically forgiving myself, admittedly, but this is one thing I'm staunchly behind. If I cannot read every character of every line of code, including packages/dependencies, that makes the hardware function and allows me to alter it as I see fit, then it is not truly open-sourced.
For me, the open-source movement is about keeping my software and hardware in alignment with my values and security concerns. If there is a part of that "open-sourced" software that is closed to me, I have no way to evaluate that and determine if I want to use it. Yes, this imposes some extremely strict limitations about what I end up with in my projects, but I'm okay with this since it forces me to think differently about certain problems.
I also don't mind that other people use product with closed-source portions or whatever, and in fact, find some of them quite good. I'm a wearer of an original Pebble to this day, and I'm fine with knowing some proprietary libraries are needed to make it go. I didn't build it, I'm not hacking on it, it's just serving my meager smartwatch needs in this instance.
What I do mind is misappropriation of what I consider a clearly defined term. I am not sure why we haven't come up with another term to mean "partially open-sourced" yet (or have we, and I am just not aware of it?) but I think it's time we did so more discerning users can delineate between the two when making a decision about products to purchase or build.
> These non-free software components are not required - you can compile and run Pebble watch software without them. This will always be the case.
This seems like a reasonable balance. They're shipping default distributions with these blobs included, but you can remove them and run the literally completely purely open source version directly instead if you prefer (although it sounds like you'd notably lose heart rate tracking, along with speech recognition & similar).
The reason why people get "pedantic" about this stuff, is due the ability in the future to get screwed over when the priority blob owner start to charge money or other pull other license crap
1. It's the other way around: because people don't care that much, that's why there is almost exclusively proprietary hardware around.
2. The people who require the "higher grades" of being open source are simply not a large enough market
3. Being open source is not a natural advantage of a product, in fact, it's more of a risk, liability, responsibility, and effort than being proprietary.
Read Reflections on Trusting Trust to understand why having little bits of binary blobs sprinkled all over your compute arch is actually a major problem. Just because it’s a hard problem doesn’t mean we’re gonna pretend it’s fine.
The general sentiment is that you cannot trust code you did not write yourself and that we need to be able to trust the person who did, but you can form your own conclusions about how that fits into the modern tech landscape.
One of the points made in that paper is that you can't even trust the compiler, even if you write the code yourself. I think this is one of the stronger points as it shows you it is unfeasible to require everybody to audit all source code before running it. Be pragmatic, know your threat model, decide who you trust and move on with more important things in your life.
FOSS enthusiasts are the worst customers imaginable. Not only are they pedantic to the absurd levels you mention, they are also political extremists and will start a witch hunt unless you and your entire company does exactly as they say in every matter imaginable.
And worst of all: They are incredibly cheap and don't want to spend any of their money on high quality products or services. Scream at every dollar they have to spend. "I'm better off with this hand-me-down computer that my sister gave me when her office job upgraded machines".
Trying to please FOSS people is like opening a five star budget restaurant for people with complicated allergies. You're going to deal with the worst of humanity and go broke in the process.
Given how easy is to put and keep hidden malware into devices, governments should demand openness in that field as well. By "putting malware" I don't mean script kiddies in their moms basement but malware/spyware planted by design, which is extremely easy to do if you're the manufacturer, extremely easy to demand/force if you're the government above that manufacturer, and extremely hard to detect if you're a different user in a different country under a government that didn't demand full openness. I know it's impossible as business rules go, but ideally it shouldn't be.
The thing is governments are the people doing it, and most governments want to be able to put backdoors in more badly than they want other governments to not put backdoors in.
Open silicon is a big leap beyond open hardware schematics and BOMs that allow people to repair boards, or redesign them to use alternative components.
Precursor is the most open personal computing device that can be built currently.
The comment I replied to was about being "fully open". That indeed goes beyond open hardware. Precursor could go further by at least using an FPGA that has great open source tooling support. It's also not impossible to fab an open FPGA but that's also another hard(and expensive) step.
Precursor goes far, but definitely not as far as currently possible.
The framework laptop , any hard drive ( meaning the hard drives , internal system software ) would not be open source.
the embedded software in a SSD , possibly, but the chips could have backdoors etc
> Above a certain complexity, there is basically no 100% open-source hardware out there.
>
> Like none of the Pinephone, Librem, Framework laptops are "open-source" to the bone.
As an aside, GNU Librephone aims to rectify that by reverse-engineering those blobs and develop their own firmware for baseband chips etc. But I am carefully optimistic about the success since it is a relatively new project and quite a moonshot, even though I would personally stand first in line to buy one if it would materialize.
Human speech is not mathematical formalism. What would even "open-source" mean in case of hardware, is there a consensus on it to begin with? Is it only 'every firmware is open-source and available', or would you want the whole floorplan of the chip?
So given that the word doesn't really apply to hardware, I believe they used it correctly (100% means the set of things where it makes sense to be used) and are not misleading. In fact I strongly dislike some of the "open-hardware" marketing of some previously mentioned devices, when that is obviously false and misleading.
I don't know, depends on a lot of stuff. If you are interested in this property from a security perspective, then no -- it's trivial to have hardware backdoors without any binary blobs.
This likely would also mean that it can't be flashed, so if you care about future maintainability, this is also a negative -- it can not be updated/fixed in the future, which may or may not make sense depending on what part we are talking about.
But if there are some kind of signature validation then it gets even more complicated (like e.g. iphone screens knowing if they are from apple or not).
> I don't know, depends on a lot of stuff. If you are interested in this property from a security perspective, then no -- it's trivial to have hardware backdoors without any binary blobs.
Well the Pebble specific parts are. This is an unfortunate state of affairs from hardware manufacturers, they are very late to the open source game, if at all.
Between the cross-licensing of hardware IP blocks and 3rd party software which never sees the light of the day, hardware manufacturers work like a secretive three letter agency to be able to control every part of their ecosystem.
I tend to understand where this comes from. It's part business, part continuation of old customs and the way they did it and being able to control obsolescence to be able push new things to the market.
However, if the periphery of the software you put out is closed source, even though this periphery is optional, it's not fair or ethical to say it's 100% open source.
From my perspective, it can be said it's open core, and it's pretty fair, and acceptable in my case, but writing 100% Open Source* (*: 100% of the open part of the software stack, exceptions apply) is not fair game. It's misleading.
Seems a bunch are angry about this, honestly, 100% of what they made/control is open source was a good enough bar for me. Specially if all closed components are optional. I value the flexibility of being able to use or not even closed stuff. It's unclear to me what the issue is, false advertisement ? This is as good as it gets for things like this, maybe the "100%" was indelicate, but I wouldn't go so far as misleading. I can also understand the hardware companies, history has shown that the vast majority of industry actors have a purely parasitical relation to open source, and have no qualms copying/stealing IP.
Personally, I'm not angry. On the contrary, I'm pretty neutral about closed-source, optional add-ons. I started playing/working with computers pretty early, and the current state is an utopia when compared to olden times in terms of Free and Open Source software (OTOH, both Free Software and Open Source is under heavy attack because of many reasons I won't enter here).
What bothers me is "100%" part of the open source claim. I personally like the Debian model a lot. It's DFSG compliant by default, and if non-free software is needed, it's attainable. Debian is "as Free as you want, as closed as you need".
I see, new Pebble follows the same model, and it's perfectly fine, but branding it as 100% Open Source is not.
I'll not discuss hardware companies. It's a can of worms that doesn't belong to that reply. Let's say while I understand some of their reservations, these reservation doesn't change that they're greedy and selfish (beyond acceptable limits).
Hardware isn't that hard to copy paste really, to make it hard you need to use really expensive processes (extreme uv etc), but otherwise, mostly you can pretty much take a picture. (very grossly speaking here, but just saying, the software is definitely a critical part)
>Another important note - some binary blobs and other non-free software components are used today in PebbleOS and the Pebble mobile app (ex: the heart rate sensor on PT2 , Memfault library, and others). Optional non-free web services, like Wispr-flow API speech recognizer, are also used. These non-free software components are not required - you can compile and run Pebble watch software without them. This will always be the case. More non-free software components may appear in our software in the future. The core Pebble watch software stack (everything you need to use your Pebble watch) will always be open source.
Debian doesn't advertise itself as 100% open source, either.
Main and Contrib has to obey DFSG guidelines, and there's an optional non-free repository which you can enable if you prefer.
Firmware is a gnarly can of worms though, and while I prefer 100% free firmware myself, companies are not brave enough to open that part of their ecosystem, yet, if ever.
Companies typically move more and more functionality to closed firmware, so they can ”open source” a thin wrapper, like a driver, that is often completely useless, and often encumbered with cryptography restrictions, strict trademarks and software patents anyway.
NVIDIA does exactly what you said. Move everything to firmware and closed GL libraries, and open source a kernel module to facilitate communication. They even created different firmware versions to prevent open source drivers to use the whole card.
AMD did the inverse: They re-implemented a fully open driver from scratch, opened up the specs, made every part which they can make (legally) accessible, accessible, open sourced ROCm and send in packages to major distributions' (main / open source) repositories. Their firmware is closed source, but it's obtainable and doesn't require signatures to enable the card. They even clashed with HDMI forums to make a libre implementation of v2.1, but the forum basically threatened them.
Intel's graphics drivers are basically the same with AMD.
Broadcom / Intel / Realtek NICs work without their respective firmware blobs, yet their offloading capabilities are disabled. Either way, the drivers are completely open source and in the kernel mainline.
Same for most sound cards sans Creative Labs. I want to hit them with a foam cluebat so bad.
Logitech's all stuff works with open drivers. They are the primary contributor to V4L standard, standardize their webcam interfaces and provide drivers or help.
> More non-free software components may appear in our software in the future.
That sounds ominous.
I can understand not being able to remove non-free dependencies that were used previously, but that sounds like they intend to create new non-free components.
Closed verilog I can accept. But in general firmware is also software, for example it has become quite popular in the recent years to execute firmware on an embedded riscv cpu. And move more and more functionality to that kind of firmware.
You have never tried to teach kids, smartphone-natives, to use a desktop, have you? The "new user" demographic has shifted from "been taught how to use windows" to "has maybe used an ipad".
The classic start menu/task bar approach just isn't as approachable as you think.
reply