Hacker News new | past | comments | ask | show | jobs | submit | lhamil64's comments login

Yeah so annoying to fly all the way up there and do an EVA just to find out that it didn't even ask for a passcode...

I found a similar question on StackExchange with a good answer https://ham.stackexchange.com/questions/9098/what-are-the-te...


In short: FM needs more bandwidth


I haven't used Macs much, but I've also had issues with multi-monitor window placement on Windows and Linux too. I use a Windows laptop at work with a single external display. For some reason, if I unplug the display to go to a meeting, when I reconnect it all my windows are still on the laptop screen, and new windows even open on the laptop screen despite the external being primary. I've resorted to just disabling the laptop screen unless I need it to screen share in a meeting.

At home I use Linux Mint and also went back to one monitor. It seems like the entire desktop is just spanned across both displays, so Windows seemed to always open on the left-most monitor. Maybe it's better now, it's been a while since I tried it. But I'm also visually impaired and use the screen magnifier, which is awful on multiple monitors. If you set the mouse to always be in the center, it centers it across all monitors, not your primary monitor so your cursor is between the two monitors. On Windows, the magnifier app centers the cursor on whatever monitor it's currently on, which I think is much more intuitive. I've noticed this same behavior across multiple DEs (Cinnamon/Gnome & KDE) so I suspect it's a deeper issue. I've thought about making some code contributions to improve the usability but I just haven't spent the time to get a dev environment set up.


I wonder if it was more of an issue with the mic and/or mic placement on phones? Old landline phones had a large mic right by your mouth, whereas cell phones have little pinhole mics near the bottom of the phone.

I feel like I've actually noticed the opposite. My parents still have a landline, although it's basically VoIP (through their cable company) but it's connected to the analog lines in their house. I've noticed they generally sound clearer on their cell phones than they do on the landline.


It’s different audio codecs and data connections which can be changed and adjusted.

Voice over mobile data will benefit from a different type of data compression relative to how data packets are handled in a cellular radio vs a wired internet.

The landline service could be as clear or clearer than mobile data, it just isn’t configured to do so in your case. I have seen VoIP setups using a high quality codec and a handset that can use those frequencies.

Phone companies use different setups that compress to their advantage for many more callers.


I'd not really call it different packet handling (except for some of the earlier, mostly 2G ones not providing FEC at lower layers and delegating some level of error concealing to the codec, as far as I remember):

The main difference is that the bandwidth available was just much lower, so mobile codecs are compressed more. (Satellite phones take this to the extreme – 2.4 kbps is a typical data rate after compression there!)

But so were e.g. international trunk lines; they squeezed a lot more than one voice channel into 64 kbps using compression, silence suppression etc.

> The landline service could be as clear or clearer than mobile data, it just isn’t configured to do so in your case.

An analog landline has relatively little chance of ever gaining wideband support, since that would require swapping out line cards at the provider, and the trend seems to be to get rid of these entirely (in favor of a VoIP adapter in the CPE).

I think I've once used "HD voice" on a "landline" when calling a mobile phone, but that only worked because my home router was actually doing SIP in the background.


Cell phone audio traditionally only covered 300Hz-3.4kHz before being lossily compressed down to 4kbps (or sometimes higher, depending on network, load in that service area, etc). That is complete shit. Recently, there have been other protocols adopted with greater bandwidth (all the way up to 7kHz, which is still several khz short of covering all the content of speech, but considerably less terrible) and less compression, but if you have audio that's actually good and not merely passable, it's probably because your phone is actually transmitting audio as voip, with a much better codec then is used for cellphone audio transmitted over the standard channel.


G.711, the standard encoding for home phone systems since they went digital, is usually filtered at 300–3400Hz as well. Chances are if you had a home phone in the 80s or 90s it was filtered at 300-3400Hz somewhere along the path.


And the history of that filtering even predates digital lines, due to frequency multiplexing: https://en.wikipedia.org/wiki/L-carrier


Ironically, you've got a better chance of getting acceptable quality on mobile-to-mobile calls these days than when calling from a landline:

The big mobile carriers actually have VoIP interconnects preserving wideband audio, while connecting to an (especially smaller) landline carrier might still involve a circuit switched path (going to the physical location of the area code dialed, too!) that inevitably forces everything through a 4 kHz, 8 bit bottleneck.


Makes me wonder how long some IT guy spent trying to diagnose the problem before hearing the news


"Damn it Jim, Barry on floor 88 killed the server again.."

Makes me think of one of the pilots' first reaction when 2 planes collided on the runway in Tenerife, from https://askthepilot.com/essaysandstories/tenerife-we-gaan/ :

> Knowing they’d been hit, Bragg instinctively reached upward in an effort to pull the “fire handles” — a set of four overhead-mounted levers that cut off the supply of fuel, air, electricity, and hydraulics running to and from the engines. His arm groped helplessly. When he looked up, the roof was gone.


OP said there's a server room in the basement, so if they are just using the servers as they were and connected that equipment to their network, then the guy could potentially access them.


If you're in the US, you can use any address you can receive mail at (work, a PO box, mail forwarding service, etc). I used a cheap mail forwarding service (it actually doesn't charge a monthly fee, just shipping and I never get mail there anyway). The important thing is to get this setup before you even get your FRN because the change history of your license is also public, so once your address is there, it's viewable forever.


This is a cool project. It would be really powerful if you could integrate Home Assistant's voice assist into this. I haven't played with it much, but I believe you can create custom sentences which would probably help with the joke telling. Or I think you can even set ChatGPT as the backend which seems like it'd make some of this stuff a lot easier (like reformatting the train times). And this would enable speech to text so you wouldn't have to mess with a phone tree and mapping dialed numbers to letters.


As someone who's legally blind, this has always bugged me. It's like the trend of "dark mode", I've always found it easier to see white text on a black background but it seems like a relatively recent trend that it's becoming normal for apps/sites to actually be designed with that in mind.

Also as a slight tangent, public transportation! The US being so car dependant really hinders my independence, and better public transportation would benefit everyone (except car manufacturers, I suppose)


> It means the uppercase you password when generating a hash. Good lord.

No it doesn't. Say your password is "Abc1". When you sign up, they would hash "Abc1". Then when you login, say you type "aBC1". The site would first hash "aBC1" and find that it is incorrect. Then it would invert the case to "Abc1" and try again, and it would work. It's basically just automating a second attempt. In fact, I wonder if it even counts as a second failed attempt if both failed.

If someone were able to make brute force attempts on the website, it would still end up evaluating the passwords the same number of times as if the inverted case wasn't checked (the attacker would just need to invert it themselves) and in fact would likely slow down the attack because they are forced into checking inverterted case passwords. But that's moot anyway because the website limits login attempts. And if the database leaked, it's not stored any differently than if they didn't invert the case.

Of course I'm making assumptions about the implementation (I didn't know they did this until this comment) and it could be done poorly but I would hope a company as big as meta/Facebook put at least this amount of thought into it.


Ok, but I thought the implication was that it didn’t do retries but just uppercased passwords.

This makes more sense, and obviously a better idea.


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

Search: