Oh man.
Again one of those projects where someone glues together an Arduino (ESP, Raspberry,...), a modem module and a battery.
I'm not sure where this is "educational" (except for the creators, of course).
I've been using hacky phones all my life (N900, N9, Sailfish, Ubuntu Touch, Pinephone, Librem5) and I really really really just want people to finally concentrate their efforts and build a (non-android) open-source phone (HW + ecosystem) that's actually usable.
Sorry for this non-constructive post, but this is a topic that bothers me quite a lot.
That means you want work done in Mesa so that the GPU in question is better supported than it currently is.
But you also want Firefox's Webrender changed to allow using the GPU in question under Linux, by default. Otherwise the browsing experience is laggy as hell for everything other than HN. That means lots of testing in Firefox, and somehow convincing them not to blacklist your GPU under Linux. (Which I'm guessing takes time since changes in Mesa don't hit every major distro all at once.)
And you also need video acceleration to work out of the box. Otherwise you're going to be trying various flag combos just to get your phone from getting hot while watching a video. And then your browsing experience probably gets laggy again.
And then you're going to need to rinse and repeat that entire process to get the baseband to work with nearly any carrier, at least in the U.S. They probably aren't going to support using that baseband on something that isn't an android phone. You'll need some reliable way around that. Is this an open research question? I don't know.
Once you have those done, try to figure out why playing music to a bluetooth speaker over this device sometimes changes the pitch of the audio! Oops, another unexpected rabbit hole.
I declare by fiat all of the above problems have been solved.
Oh no, I forgot about battery life.
Now I've got a summer project to figure out why suspend sometimes-- but not always-- freezes my phone.
After that I need to figure out the signal path between baseband and Linux to figure out why getting a call sometimes-- but not always-- wakes the phone so it rings reliably.
These are all hard things. The idea that motivated rando open source devs can roll up their sleeves and solve phone usability is laughable.
A lot of these kinds of problems go away with vertical integration and limited scope. E.g. if you only want to make phone calls and send SMS (or the internet application of your choice) so you can call it a phone, it's not terrible. You can write that. When you want to run a massive black box like Firefox on top of another massive black box like a proprietary GPU, it is terrible.
None, but the point is that trying to make a dumbphone, using Linux as an ingredient, allows each part of the product to be very specific about the other parts, whereas trying to add general phone support to Linux (say, if you plug in a USB modem) will require either a lowest common denominator or an inconsistent experience, and will have abstraction layers in the middle making the software much harder to develop. Consider that the SMS app for My Linux Dumbphone can open /dev/ttyUSB5 and send AT commands, and the experience as a whole is tested and edited by one person until it works well, while the one for KDE has to use some KDE API which either adapts to KDE Connect (which has to follow an already-designed protocol) or to a Linux kernel API which is implemented by a lowest-effort driver.
How does Precursor suit you? It's an open core CPU implemented on fpga, no modem included tho (feature not a bug etc), not android but from the ground up rust os "xous"
My experience with open source linux phones is that they can never make basic decisions like which package manager or ui framework to target, so you end up with five completely distinct base operating systems. Some can make calls, some can receive sms and some can suspend resume. None can do all three. If they’d picked one standard approach they could have all those things with 10% the effort I’ve seen go into those ecosystems.
I don’t think there’s anything particularly hard about producing an open source linux phone with modern hardware and a supported base operating system that is competitive with a typical dumb phone.
However, none of the companies that have tried to make an open source phone are product focused enough to build such a thing.
Problem with a non-android thing is that you lose the software platform it gives, as well as the ecosystem of apps. To do a new thing looks time consuming - the hardware and firmware has to be solid, the UI can't just be a desktop Linux in fancy dress, and then you need to write apps for stuff.
I sometimes think through doing a garmin-type thing with an e-ink display and the features I want - it works out to need way too much time: well-integrated hardware, decent low-power firmware, then the interface and custom map software is just a bit much for a spare-time thing for me (a pick one or two sort of deal). Android solves at least the ui and app problem in that case.
The title is a bit misleading IMHO. It's more like analog vs digital.
After all, from an electrical point of view they're usually just potentiometers and you can build them either as rotary or as linear potentiometers, but it's just a wiper on a resistive conductive track... (of course there are exceptions that work differently and use hall effect or optical sensors).
The article only talks about the actual circuit that is behind that potentiometer.
Having built some MIDI controllers myself in the past, I noticed that rotary potentiometers allow you to better "decouple" arm/shoulder movements from hand/finger movements. I.e. when you're standing and and holding that knob, It's easier to make precise adjustments when there's a rotary knob you can "hold on to" and slowly twist your fingers, whereas with a linear potentiometer I usually have to keep a finger on the surface next to the knob to "compensate" for involuntary movements coming from my body and arm...
Yes, this is the same for controls in a car. Whoever thought a touch display was the way to go? Our old car had twisty-nobs that you could feel direction already on the grip. No need to look on the symbols what they adjusted. Our "modern" car has still twisty-nobs (we made extra sure of that) but you can't feel the direction because they are perfectly round with a tiny tiny nob for direction. Why do I get the impression development goes backwards?
The hardware is much cheaper, but it is also way cheaper to engineer, and because a touchscreen is a very one-dimensional interface, many questions don't even need to be asked. There's no texture, shape or feedback in a touchscreen, for example.
BMW is a good example. They started putting in that horrendous double wide screen/touch screen removing all buttons (the radio 1-8 shortcuts), temperature, heated seats, fan speed etc onto the screen.
This of course has made their dash design a lot cheaper. The only things remaining are:
Volume (which can be pressed for on/off/play/pause), previous, next, park-anywhere-button, front and rear windshield defroster.
One thing that is amazing about BMW's volume control:
It clicks, but the clicks don't corelate directly with volume change. It depends on how fast you turn the knob. Turn it 5 positions slow = volume += 10. Turn it 5 positions fast = volume += 5. To prevent you from accidently turning it too fast and blowing up your eardrums.
BMW actually seems to be quite intentional with details like this. For those who appreciate thoughtful human-centered design, it quickly becomes clear that many of their choices reflect unusually meticulous work and attention to detail. But I wonder if this is shifting, as fewer people seem to understand the difference.
Are there physical controls that mount on a digitizer? E.g. instead of a rotary dial on a potentiometer, the bottom sits on a digitizer that can translate the "touch" event into circular motion. Same with buttons, like with a keyboard membrane, but capacitive. Wouldn't that be cheaper?
That’s not addressing the right issue. Encoders and switches are not the expensive parts. What’s expensive is designing the dashboard with precise holes, before you actually start the manufacturing process, lining up the component with the hole and cap, making sure they actually work etc. Compare that to a dashboard of the new Tesla robo taxi, which basically has a complexity of a TV mount.
But you don't need to line up the holes if you can just plonk the component down anywhere and then program the software with the locations of the components after the fact.
Ford does this on the MachE and I think the F150L. They have a rotary dial for volume control and that is just mounted directly to the touch screen and uses some sort of wipers to make contact for the control surface.
This is also my experience. I'm not a DJ but I perform live electronic music using various MIDI controllers. If I quickly want to add or remove a sound, like a kick drum, to/from the mix, a slider is best. If I need fine control over a parameter, like a low-pass filter frequency, a rotary controller is usually better for the reasons you mentioned.
As alluded to in the article, rotary vs. linear seems to be a proxy for the circuit which actually influences the sound. I would think that anyone claiming "mixers with rotaries always sound better" does not fully understand how they work. There's a lot of those kind of claims in the music scene.
I agree that what's going on in the EU council is a very big problem.
But what is that website about? They want my money? for what? It doesn't look like it's a legit NGO, let alone a European one.
> Reclaim The Net is supported by you, those who care about the future of the internet and are concerned about Big Tech, media, and governments controlling speech and eroding liberties.
> Become a contributing member to keep fighting for individual liberty online. Not only does your donation support our work around free speech, alternative tech, privacy, and individual liberty online, members also get…[list of perks]
You have to enter a made up email address to get to the "choose your membership" page
A used Thinkpad.
(or any other used non-consumer grade laptop)
Most companies either rent their laptops or somehow sell them after a couple of years. They are usually in good condition and often the reseller gives you 1-2 years of warranty.
I've bought a used X250 for <300€ a couple of years ago and I could not be much happier. Of course, the specs could be a bit better, but for most of my tasks (HW + embedded Linux dev) it's sufficient. For everything else i can spin up some beefy server somewhere in a couple of minutes.
And since the hardware is on the market for quite some time, driver issues are mostly resolved.
Bonus: used Docking stations and spare power supplies are cheap and the battery can be hot-swapped.
Bonus2: since it's already slightly beaten down, making another scratch doesn't hurt as much as if it would've been a shiny new macbook.
edit: I think the official term is "refurbished". I can't see myself ever buying a new device again.
It's a sad story.
My spouse is working for the city in some legal department and she was happily using LiMux for years with no big issues.
The main problem was that the IT department was understaffed and underpaid...
One reason for their switch might be that Microsoft thought about opening up a big office here.
Another reason might have been the study conducted by Accenture [1], who have some close ties to Microsoft...
I also enjoyed reading the interview of former Munich mayor Christian Ude [2]. Apparently, Steve Ballmer was interrupting his ski vacation in Switzerland to visit Ude and personally try to convince him to ditch LiMux.
> It's a sad story. My spouse is working for the city in some legal department and she was happily using LiMux for years with no big issues. The main problem was that the IT department was understaffed and underpaid...
I worked on LiMux in the developer team at the start of my career. HN is a village, lol. And the situation is more complex, and long enough has passed for me to detail out what actually were the problems without revealing anything top secret...
1. most of the desktop hardware was OLD. Like really fucking old. We're talking of systems with 256M of RAM. Anything would send these into swapping. But instead of blaming the finance department for not upgrading the computers, everyone was more than happy to blame LiMux because many people hoped that enough blaming would bring Windows back eventually (as it did...)
2. A lot of the hundreds of sites that the city of Munich has weren't connected to fast fiber, but via 10/10 SDSL (or slower) links. That's enough for Active Directory to work, and most sites had cache servers on-site to make life bearable, but still: everything was SLOW for a lot of users. From what I hear through the grape vines, that has changed at least for everything inside the Mittlerer Ring demarcation as M-net/SWM built out FTTB across the entire area, but some sites more remote still are on crap links.
3. LibreOffice, or rather OpenOffice was shit back then - I was there right when the fork happened. (And from what I hear, it's not gotten much better... developing an office suite actually requires funding which barely anyone wants to provide)
4. Many of the special applications ("Fachverfahren") were only available for Windows. Some (e.g. SAP) were available as Java apps (with all the problems JVM has, particularly being a memory hog), a few were available as Linux applications but usually in rpm format and not deb which made every update a PITA with alien (LiMux was Ubuntu based), but the utter majority were Windows-only. Some could be made to work with WINE, but some (particularly those interfacing with proprietary hardware such as specially hardened printers) still required a few Windows workstations here and there.
5. We were fucking understaffed. Like 4 FTEs working on packaging and development, but a whole externally sourced test department (that was, to be fair, really needed to catch regressions, and there were a lot of them). But each and every single one of my colleagues were absolute experts and a joy to work with and learn from. Without them, the situation would have been much worse.
6. Political interference. Not just from the city government and its bullshit, but especially from the entrenched "micro fiefdoms" in the administration. No one wanted to cede control to us or the central IT@M organization that was being formed when I was there, instead they all wanted their own decentralized teams (dIKA). Some wanted to opt out of LiMux entirely, and had good reasons for that (chiefly, their applications not running on LiMux).
7. Dieter fucking Reiter, the successor of Christian Ude as mayor after the 2014 elections, as well as the Social Democrat-Conservative government that came into power with him. Ude, for all he turned wrong after he left office, was a staunch protector of LiMux, and we all knew what would come once he left, and so it inevitably happened. And that's just one thing in the long list of reasons to despise Reiter.
I dug back into the archives and found two old comments of mine back when my memory was more fresh [1] [2]. Happy reading. To add a few corrections to my top post - the upper limit of machines back then was 2GB of RAM, usually 512 to 1024M, and it was 10/10 fiber not SDSL that was the norm.
> Hackers have installed password-stealing malware on the devices of multiple Worldcoin Orb operators, TechCrunch has learned, giving them full access to the Worldcoin operator dashboard.
I've been using hacky phones all my life (N900, N9, Sailfish, Ubuntu Touch, Pinephone, Librem5) and I really really really just want people to finally concentrate their efforts and build a (non-android) open-source phone (HW + ecosystem) that's actually usable.
Sorry for this non-constructive post, but this is a topic that bothers me quite a lot.