For me PulseView unfortunately has been very buggy and I never really got it to work (neither with an old Saleae 8, a new Saleae Pro 16, or an FX2 clone) well and without constant crashes.
I tried on Linux & mac, but never could get it to run well. I'd be super curious to chat with someone who had a different experience on what you've been doing differently from me!
I love the idea of Sigrok, so would love to get it to work (well) for me
PulseView shouldn't be crashing a lot at all, honestly. Were you running the nightly or the 0.4.2 release? The 0.4.2 release is rather outdated, I'm working on making a new release soon to fix that.
Not my experience. I got a cheap Sparkfun logic analyzer on a whim and it sat idle until I had a work problem that I spent a lot of WFH time debugging with it using Pulseview.
I later recommended that we buy a Saleae analyzer just in case the SF one was hiding a problem and I didn't find any substantive difference between the two.
It is my firm belief that everybody should have one of those $10 FX2 boards in their drawer, either for debugging some electronics board stuff (arduino and up), or just for learning about digital signalling. $10 and Pulseview is all you need!
SD cards do not increase the memory available to user applications. They are storage devices, even if the technology behind them has the word memory in the name.
It's not the memory that's the problem, it's that games like FGO require 10GB or more of flash storage which is most of a 16GB device particularly when you consider overhead for software updates. It's not like the game has high memory requirements but it sure has a lot of levels, textures and stuff.
It's amusing the the IBM Mainframe world still uses the word "storage" to describe RAM.
- Enable VoiceOver (Settings -> Accessibility) and learn how to enable/disable it (triple-tap the side button. Might be difficult for elderly) - Apple video on it: https://www.youtube.com/watch?v=qDm7GiKra28
- Having a learning partner really helps the blind person. Try to learn to use a phone blind with him, it will allow you to help debug his (most definitely occuring) issues
- Watch some videos on how blind people use the iPhone, lots of tips there. For example Molly Burke, or even simple ones like this one: https://www.youtube.com/watch?v=3FVjLXIaBC4
- For elderly, an iPad is really nice. Especially as dexterity gets worse it's easier to use blindly. Also usability between iPhone and iPad is almost the same, so easy transition between both (i.e. on the go)
- For movies, check out Greta. It plays the AD in parallel with a movie via the iPhone - so they can watch movies together with the family, without everyone listening to AD https://www.gretaundstarks.de/starks/GretaAndStarks
And bring lots of patience :)
What is really amazing is how fast people tend to improve: VoiceOver lets you adjust the speech speed etcpp, and so it "grows" with you
I worked under a blind manager when the iPhone first came out. He was a former dev before his vision started to go. He was a power user while blind, and knew twice as many hot keys as I did, had his screen reader speed cranked up to a rate incomprehensible to me.
I remember how happy he was with the iPhone. He said it was the first device he was able to use without special accessibility software, and that was in 2007, I imagine the experience is better today.
I’m sure you’re (OP) already on the ball with ways to help him, but if you haven’t looked into movies with described audio, apparently it makes a whale of a difference.
One other non-obvious but major thing there for a newly blind person using an iPhone - the Magnifier app can generate basic spoken descriptions of whatever object or text you point it at [1][2], including following your hand to tell you what text is on button labels [3].
Apple accessibility including VoiceOver is amazing and from everything I read second to none. Though I don’t have first hand experience on that, I did spend several hours one time lined up for an iPhone talking with a blind girl - she was showing me how she uses both her Mac and iPhone with voiceover and with the screen totally black. Was a fun night.
Is there a website that works like youtube but for audio only? Because otherwise thoughtfully produced videos are going to be the best way for someone who doesn't know how to use a screen reader efficiently to gather information.
Podcasts generally are the audio alternative to YouTube. Thankfully, podcasts remain largely decentralised and aren't restricted to a single website or service.
Podcast search is something of a challenge. There are a few websites that claim to do this though in my experience they do so poorly.
Podcast Republic (Android & iOS) is an app I've used that has an excellent podcast search capability --- both podcasts as a whole and individual episodes, with shownotes indexed (protip to podcast creators: your shownotes are themselves and excellent discovery tool, do not neglect them).
PR isn't my main podcast driver (I use AntennaPod from F-Droid), but I will bring it up to search for specific content when I need to do so.
Either I'm not blind or I'm not using a phone, because I have an android. With pass phrase, thank you very much.
Both IPhone and Android have screen readers, with Android having the ability for alternative sr-s and voices. The Iphone is more integrated as far as I know, but the default google apps are pretty accessible on Android as well. There is a mailing list for blind android users if you want more advice, but if your grandfather is used to the Iphone, there is no reason not to use it. The default apple recourse on the topic is applevis, if I remember correctly.
you are right. the sr pronounced "used" as "use" and I've took it for more generalizating statement than it was. Still, the idea of removing security because people are presumed unable to enter their passwords or because it would make it more convenient for someone else triggered me badly.
The Game Boy ROM is so much fun to dump in various ways. For example you can clock glitch it by just by scraping a contact with a jumper wire:
https://youtu.be/64FgfhfvJ4s?t=154
Gameboy is really slow when compared to modern hardware. One ECDSA signature that takes around 100ms on Trezor (32-bit CPU @ 120 MHz) would take around a minute on GameBoy (8-bit CPU @ ~4 MHz.
If we're talking about GameBoy Advance (32-bit CPU @ 25 MHz) - this more plausible but still 5 times slower than Trezor.
I think waiting a full minute is a perfectly justifiable trade-off for a dystopian future that at least forces people to have an iconic '80's handheld strapped to their hip. If we're headed toward a dystopia, we can at least try to set the stage for a certain standard of aesthetics.
Unfortunately the software support for the BladeRF 2.0 micro is not yet very mature - the official installation instructions do not work (don't install udev rules etc).
I would recommend waiting a couple of months and see how the ecosystem develops.
The HackRF ($300) or RTL-SDR ($20, but RX only) are the go-to hardware for consumers/hackers. These devices are more limited than some of the newer SDRs, but the software support is a lot better.
For software, the HackRF is probably the best ecosystem. It's open hardware, and the firmware is GPLv2.
The software ecosystem for SDR is pretty messy, pretty much all of the consumer/hacker SDR software is hard to set up correctly, and Linux only. The easiest thing to use is the Pentoo distro, it has all of the common tools, up to date and included in the base image.
You nailed it for the devs but you gotta' say it to people who would pay for it too.
Decentralized GitHub would synergistically leverage our existing cloud infrastructure to provide unprecedented collaboration that is open, robust, efficient, and focused.
"crypto" baiting is like the funniest trend ever in the Stock Market lately.
Kodak is riding that pony home ... (noting I live in Buffalo, just down the road from Kodak's home turf in Rochester and I'm a pretty avid photographer - http://www.instagram.com/crispyfotos/).
You got to ironically buzz to be cool today?
Pretend you didnt get it, so all those d* who didnt get it can lecture you.
We are deeply invested into the idea of the Seagullarity!
Actually that's the FIRST time I've ever heard of lattice. Is that a real deal? Not trying to feed into the hype here, but from a math perspective I get fascinated by concurrency
Yeah, a cryptocurrency called Rai currently uses it (maybe IOTA too?). Essentially, each account gets its own blockchain and they're connected together using a DAG data structure.
SIA coin is a similar concept. They even have video hosting/streaming on their development roadmap.
Decentralized storage, filesystem and social media seem to be the most valuable use–case for blockchains aside from the inherent value of cryptocurrency.
It's funny that there's already a Gitcoin project, however they do NOT have a token:
https://gitcoin.co/
The goal of the project is to incentivize FOSS development, similar to Bountysource, except without requiring participants to trust a central party. It's pretty cool!
The issue is that the features we use along with git, many of which github provides, are not decentralized. The true but tired argument that git will continue to work when github goes down totally ignores this issue.
Yes, git still works. But we don't just rely on the features git provides.
So this isn't really anything to do with Git then is it? So why joke we centralised Git when really we centralised a bunch of other things that are not really anything to do with Git?
It's also the issue with git, if it goes down and you don't update your local clones ~daily (or as other mentioned don't have system in place that would allow you to update somewhat locally).
You can still work with your colleagues by pushing and pulling your own repos without involving GitHub.
I think centralised CI is the real problem. I don't have the compute power in my home to run our full test suite, so I can't push with confidence without my CI cluster.
Issues and other GH infrastructure is arguably a bigger problem. That metadata is locked within the Github silo with no easy way to export it elsewhere.
This is indeed the crux of the problem. I've been thinking about this a lot (and I wouldn't be surprised if it exists already), we need a decentralised method of storing issues and other things inside our git repos.
https://github.com/neithernut/git-dit provides a distributed issue tracker inside git, without cluttering the repository with unneeded files and also gives the possibility for having tree-like conversation, referencing issues and so on.
Unfortunately, no non-cli frontend exists right now (feel free to build one, shouldn't be complicated). Also some convenience is still missing, but could easily be integrated.
What's also missing is a way to give users of the tool access to a repository where they can submit issues (which then could also be used by a web/gui frontend for the tool). This is not the domain of git-dit itself, but a solution needs to be found. One idea would be a publish repo (where everyone can push) which automatically does some sanity-verification on the issues and forwards them to the maintainers repository... or something like that.
Also, https://github.com/vitiral/artifact/ is a really nice tool to do planning of an application or library inside a git repository. I am currently starting using it in iamg (https://imag-pim.org) and it is really wonderful. The author currently does a reimplementation of its core functionality to make it even more powerful.
If you think about it, there's no particular reasons why the metadata can't live in (and be tracked by) the repo itself.
Issues could live in /issues. Simple command-line (or GUI) tools could edit them. I'm thinking in particular of how password-store[0] makes tracking history in a git repo invisible: it Just Works™.
Discussions could live in /discussions, stored in something like RFC822 format. Again, simple CLI (or GUI, if you swing that way) tools could manipulate this easily.
A wiki can, again, live in the same repo.
PRs are a little different, since they really do need to live outside the repo. But what is a PR other than someone saying, 'hey, please pull my branch into yours'?
PRs and other things could also just live in a "shadow repo". Even if just by convention.
You have a `Product` repo and a `Product-meta` repo.
The biggest issue I have with using git as a truly decentralized system is remote management. Unless you want to be manually futzing with remotes on every single client and pushing/fetching from others correctly, you need some kind of central server.
I really think there is a hole here for a product that works with git underneath, but gives a nice easy way to manage all that complexity.
Also, the workflow on Github is one many people like, and it differs a bit if you have to use git "the old fashioned way". Not that it's hard or impossible, but it differs. I can't imagine explaining the GitHub-less workflow to my colleges..
There are several attempts at tracking issues inside a repository. What we really need to sell the concept, though, I think is one that can reasonably sync with GitHub Issues. GitHub Issues are a reasonable front end for issue reporting for casual and non-technical users and if you can interoperate with them you don't have to reinvent that basic CMS.
Every now and then I sketch ideas on the subject, but haven't yet gotten someone to pay me to build it. ;)
GitLab CI is really sweet, because you deploy your own runners (workers) whereever you want. Downside is, the control is not a standalone CI app but a part of GitLab (or I'm unaware about something).
Drone is very promising but last time I've checked the documentation had some holes in it. The website is "coming soon" and IIRC it's like this for quite a long while.
I'm unaware about any CIs that are usable with local repos. Would be neat to just run a local command and it would spawn a worker somewhere (local or through a remote coordinator) and run the tests on whatever I have in the working tree, just like it happens with centralized repo+CI combos.
It's too frequent I find myself doing `git commit -m 'Fix that stupid typo in previous commit'`.
We're working on a 'CI only' mode so you can easily use GitLab CI without the rest of GitLab. This is already possible but now it requires some configuration.
We centralized a decentralized communication system too. (eMail)
Decentralization just doesn't work too well in practice for whatever reason. Everyone is behind a NAT/firewall, everyone has low computing power, its hard to regulate, etc. This all leads to a centralized solution being easier.
I think the current best thing we have is centralized but open source and encrypted, which gets an "okay"/10 from me.
> Decentralization just doesn't work too well in practice for whatever reason.
Because it's inconvenient. Centralisation is convenient, it gives a single discovery and synchronisation point. Decentralisation makes discovery much more difficult, and requires adding separate synchronisation mechanisms. It generates friction and cognitive overhead.
Even more so for "side-services". Sure your VCS is nominally decentralised[0], but what about bug reports? Contributions? Notes & docs? There were distributed bug trackers efforts back in the early 10s but… they didn't really work IME, they were not convenient or practical.
[0] though even without a single giant point of failure, most project would still have a single canonical master copy, a really mesh/distributed contribution system is very rare (Linux's tree of integrators/forks is probably the closest?) and none of the current VCS makes mesh/point-to-point collaborations really convenient
That's kind of missing the point, everyone's git local clones are still there, I can still work on the code. Git's decentralisation is meant to make sure work doesn't stop altogether when the remote is down.
The major feature of git is that it's distributed, not that it's decentralized.
Git's got two big features over SVN:
1. Automatic, private, per-user branching. Git's even nice enough to keep the private branches out of the main repository, and lets you pretend to be the authoritative repository without creating a branch if you really want to. This is what clone/push/pull actually does, and it's what a distributed VCS really brings to the table. It lets every dev pretend to be the project manager when they're writing their own code.
2. A much improved merging model. The graph model of git is just much better than the linear model of SVN.
The second one is what people thought they wanted when they started using git. The first one is what they didn't know they wanted before they started using git.
Git gets around the problem of "Well, if we do #1, how do we know which repository is authoritative then?" by saying, "We're not solving that problem. This is an exercise for the users that's easily solved by file permissions." So by refusing to solve that (rather hard) problem, the VCS becomes internally decentralized. That doesn't mean you can't or shouldn't centrally manage your repositories or have an authoritative repository. It's just that git itself doesn't care about knowing which repository is authoritative.
Bingo. People think its hard to self host. Its not. They have an omnipackage that you install. You run updates. You enable the automatic backups. Problem solved!
The VCS is still decentralized (you can share code with your neighbour or across the world), it's the administration (tickets, PRs, etc) that aren't.
I think it'd be fairly straightforward for github or a competitor to store those things in git as plain markdown files, either alongside the main source code, or (as it does with GH Pages) in a separate branch (that has nothing in common with the master branch but it's still in the same repo).
No way to build my npm dependencies.
So the day github would really crash/lost some files, the package decency system thing is dead.
That is a very exciting scenario... as exiting as if google would forget to renew google.com and would have no legal right to get it back.
I tried on Linux & mac, but never could get it to run well. I'd be super curious to chat with someone who had a different experience on what you've been doing differently from me!
I love the idea of Sigrok, so would love to get it to work (well) for me