Hacker Newsnew | past | comments | ask | show | jobs | submit | jmux's commentslogin

I’ve been wanting to get rid of Spotify for months as the service has been getting worse and worse and this might just be the straw that breaks the camels back.

Does anyone know of alternatives with 1) decent discovery for new music 2) preferably not self hosted 3) a functional Linux desktop app 4) allows downloading playlists for offline listening

getting all of these in one place and having them work well is why I’ve been stuck with Spotify for so long :/


if you're OK with browser-based and youtube and local tracks: https://dj.t-tunes.com/

Not sure about Linux but Deezer is decent. You can even upload your MP3s and listen to them in any device with the same account.

This is a really method for solving that problem! I wouldn’t have thought to use the tangents but that makes perfect sense


when I was at JPL, Akins laws (html version) were linked on the front page of the wiki. still one of the best (funniest) sources of engineering tips I’ve come across.

My favorite is still Mar’s law:

> Mar's Law) Everything is linear if plotted log-log with a fat magic marker.


A good solder sucker is your friend.

I have the SS-02, and I like it - I had one of the cheap blue ones first, but the pliable rubber tip really makes a difference. If you’re soldering smd by hand, it’s more than worth the $20


I hadn’t seen this before, this is sick! thanks for posting it here :)


this is super cool!


I love reading these, for some reason the super remote mundane infrastructure is fascinating


The USB-C step is humongous, and hard to implement.

the complexity is high, but how else can you tell a cable that supports USB4 (40GBps) from one that’s only good for charging your phone (and everything in between)? users aren’t going to be able to tell the difference (using a cable with no data lines is already a super common issue with people getting into MCUs) so the device needs to be able to tell how much data and power the connected cable can distribute automatically.

this also why usb-c extension cables (M-F) aren’t spec complaint

it’s a real cool port, but the complexity demon is definitely present in the spec :)


but how else can you tell a cable that supports USB4 (40GBps) from one that’s only good for charging your phone (and everything in between)?

By attempting to link up at the highest supported speed and downshifting if there's no valid signal? Ethernet had this figured out decades ago.


USB-C doesn’t only carry USB data.

I’m not sure if e.g. Displayport even has the capacity for link training (and there are USB-C to Displayport cables that have to support legacy devices that know nothing about USB); HDMI (until 2.2 or so) definitely does not.

It’s ok to not agree with the USB-IF’s tradeoffs in their solutions, but denying the complexity of the problem space can be a hint that you don’t sufficiently understand it to pass that kind of judgement.


Intel has a flow for how link training is done on DisplayPort.

Probably shouldn't be surprised but it involves communicating over the AUX channels. Is this something that a sizable % of computers can do? For some reason I thought aux channel was semi free for use, that it could be for Ethernet or USB in a pretty naked form. Didn't realize that needed mode switching?

https://www.intel.com/content/www/us/en/docs/programmable/68...


Ah, so maybe DisplayPort has mandatory link training then, which would indeed allow unmarked cables.

But to GPs point, there still needs to be a way to tell the source that a given cable is a USB-C-to-DisplayPort one in the first place. So why not include the metadata on what signal grades it’s rated for in that same indicator? That’s exactly what e-markers are.


It's a protocol they designed, so they could do whatever they wanted between the initial linkup and carrying data, including link training.

but denying the complexity of the problem space can be a hint that you don’t sufficiently understand it

...or that I understand more of it simultaneously to see that it could be made much simpler.


They did in fact not design all protocols running over USB-C, as I’ve mentioned.

This allows it to work with other ports without putting a complete link speed protocol converter into the cable or adapter.


This means cable might start at speed which is too high and get horrible errors if the cable is bent.

And even with Ethernet, that autorating has plenty of downsides. I've had a cable which I accidentally nailed through, so sometimes it could only connect at 10Mbps. It took me a long time before I realized it needs to be replaced, precisely because it'd just downshift instead of throwing any errors.


USB has had retries since the beginning, so slowing down the link to adapt to the current conditions isn't anything new.

precisely because it'd just downshift instead of throwing any errors.

That's "a feature, not a bug".


> Hope the documentation is correct (it isn’t)

real

compared to every exception-based language I’ve used, rust error handling is a dream. my one complaint is async, but tbh I don’t think exceptions would fare much better since things like the actor model just don’t really support error propagation in any meaningful way


A few months back I built a scraper for camping reservation sites, starting with recreation.gov.

if you think recreation.gov is bad, wait until you see the sites state parks use for reservations - especially those ran by usedirect

example: https://www.reservecalifornia.com/Web/


link to your scraper?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: