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

I think subway rail systems do have "real live location", but whether that information is consistently provided to public distribution for use through apps is a question mark.

I suspect most systems are a mix of your platinum, gold and silver (and kidding me).


Lots of systems have some sort of real location data, but it can be... shaky.

In Dublin, train 'realtime location' is, AIUI, based on arrival at stations plus time-based estimate. This _usually_ works okay. Buses have transponders which register when they pass a stop. Or, ah, well, buses usually have transponders, and those transponders sometimes work. New buses sometimes lack them, as do very old buses used for covering capacity problems. If a bus without a transponder is used, they seem to just estimate where it is based on the schedule, which is useless. If a bus without a transponder is inserted out of schedule (they sometimes do this at peak time) it's totally invisible to the realtime system. Sometimes, the transponder isn't picked up, and then the bus will appear to hang around for a while and then abruptly teleport a few stops forward. Sometimes, a bus's transponder doesn't seem to start working when the bus starts up for the first few stops.

Still, it's better than when I was a kid, when you really just had the printed schedule, assuming the rain hadn't gotten to it.


Transit telemetry is inherently spotty on these public-facing applications.

If it's like other systems, it will resort to transit schedule estimations when data is missing and then try to sync as live data becomes available.


And unfortunately, like most apps, it never bothers telling the user when the data is accurate, and when it's a guess.

   > My TVs are on the IoT network so that I can control them from Home Assistant, but they're blocked from accessing the internet. NS lookups are redirected or blocked (53 redirected to my local DNS resolver, 853 blocked),[...]
That's great, good for you that you can do that.

Unfortunately, from LG's surveillance capitalism point of view, the 0.001% of LG owners that can even think about doing that isn't even a drop in the bucket. They don't care about any one individual, and the vast majority of individuals don't care or understand what LG is doing as long as they can watch TV.

It's only a matter of time before another Cambridge Analytica situation pops up, except with better tools and vastly more data. Or maybe something we can't even imagine yet enabled by simply re-purposing ad-tech into something political and malevolent? Some people will be wise to it, of course, but if enough are caught up in it, it won't matter, we all lose as a whole.


  >...vocation of choice is misaligned with your personality...
I also kind of sense this.

The OP mentioned they were doing systems engineering. That's a very particular hellscape of grinding details. It involves being comfortable constantly dealing with a lack of control and flow. The good news is there many different kinds of work. I hope they can find their path.


It really depends on what the individual goal actually is.

I think engineering curriculums “stop short” on mathematics just as it starts becoming interesting, more generalized and before connections start becoming easy to see and remember. Math is often handled as a bag of tricks.

A lot of engineers would do well to review mathematics at a deeper level than their undergrad days, and that can mean hitting up real analysis, abstract algebra and other topics from scratch in a proof theoretic way.

Once that mathematical fluency is achieved, it becomes possible to ingest other topics at higher levels of sophistication, IMHO.


I have never reached that level of Mathematic fluency very honestly. I came by with my very mediocre level of Math, and I still somehow managed to pass General Relativity.

I still couldn't Mathematically proof anything if a gun were held against my head. I however do apreciate the precise language of math, which I greatly enjoy for describing problems and solutions with incredible precision and little room for interpretation.


XML was a good, well-intentioned idea.

The problem, IMHO, was that rampant "xml-abuse" in the naughts. ws-* standards and over-engineered garbage like SOAP ("complex object access protocol") made people loathe XML.

I did like JAXB in Java, XLST, schemas, XPATH. Never got into XSL, but it seemed like good thing too. It worked best when your tooling manipulated it for you or at least helped you in an intelligent way. Much of the hate for XML came from situations where you had to deal with someone's over-the-top-one-size-fits all schema without the benefit of tooling to at least hint you in the right direction.

It still survives in WPF and c# *.proj files. If it were just me, I would still use it for object serialization. But json is king now even though it's inferior.


It's non-trivial to implement XML parser in a secure way, many stdlib ones are insecure by default. That should just not be a thing. XML has a bunch of vulnerabilities very specific to it, XXE is the most well known one, but you also have a bunch of DoSes due to expansions and XPath injection etc.

An object serialization format should not have a bunch of footguns and vulnerability categories specific to it.


The funny thing is that JSON parsing is usually kinda unsafe in it's main target language JavaScript, and usually safe in other languages, because of the `__proto__` prototype pollution.


It's trivial to make a secure parser. The problem is that the secure parser doesn't follow the standard because the standard mandates insecurity.


I think XML's main problem is the ridiculous hype-wave that started in the late 90s. I really didn't want to see and hear XML anymore at the time. It was clear to me that it was no more and no less than a slightly awkward toolbox to build your own domain-specific language. Stupid as some of the later hype waves were, most weren't as stupid as the XML hype wave (with the notable exception of blockchain all the things).

XML is actually okay to work with, I don't mind it. XML schemas, XSLT and such are a little more... special, but also used much more rarely.


Honestly, some of the worst aspects of SOAP were legacies of XML-RPC. Some of the remaining messy parts were often "yes, you can not implement that, but then if you ever need functionality X, Y, Z - you will be fucked without this complexity".

Similar to how we have DER in ASN.1.

The rest in my experience was often related to crappy "generate me XML interface from my crappy Java/.NET class" because enterprise software demands speed of development over everything else, even if that speed is taken away by meetings


SOAP seems totally in line with the XML philosophy.


    > You can learn something like ~90% of useful SQL in an afternoon.
Oh, HELL NO!

It's an ugly little language that one has to come back to and re-learn over and over at different levels of sophistication. Nothing wrong with that, but to suggest it's trivial is a gross mischaracterization.


> different levels of sophistication

Most of those are not necessary for 90% of use cases

I'm not taking the piss either

All most people really need to know is table CRUD, row CRUD, and a bit about indices.

For anything more advanced you'll need a DBA, but IMO you unless you are scaling like crazy you will not need much more than that for SQL knowledge. It's really, really not that complex for most use cases


You should also learn joins and ordering/pagination. But that can be on day 2 :)


I consider those to be part of basic Table CRUD, but yes, absolutely. :)


I’m a DBRE, and also happen to like SQL. With that as a disclaimer, I really do not think it’s a difficult language to learn. Learning the intricacies of your RDBMS’ behavior for various functions (like MySQL’s ORDER BY and GROUP BY optimizations) is complicated, but that’s what docs are for.


   > I really do not think it’s a difficult language to learn.
Neither do I, but there's huge distances between "spend-an-afternoon-intro-on-it" and "learn-it-well-enough-for-occasional-work" and "learn-it-enough-to-build-serious-databases".

Of course, everyone in HN is "advanced" so what do I know!


> learn-it-enough-to-build-serious-databases

This is more about infrastructure than SQL though. You don't need to know any fancy SQL to do streaming replication or whatever, for instance.

You're correct that being good at Managing Data is a complex domain with a lot of gnarly bits, but I was talking about Writing SQL being fairly easy


There is plenty advice around for "how to ask" (really, it's the same if you know the person or not). It all boils down to a Calvinistic "show you're worthy" kind of exercise.

But what about advice for giving help to someone?

There's plenty of ways that giving someone help can go horribly wrong, and I think that it's not uncommon for people to be blindsided by such a request.


A pretty incredible answer to your question comes from a perhaps wholly unexpected source: Hunter S. Thompson, in a letter responding to a friend's request for life advice:

https://fs.blog/hunter-s-thompson-to-hume-logan/


What great writing. I should go read more of his stuff.

I’m definitely borrowing the phrase “galloping neurosis” the next chance I get.


Beautiful!

I did have in mind something more like the Socratic method, asking pointed questions of your mentee, guiding them but not pushing them. I suppose that in a weird way that essay is the Hunter S Thompson idea of the socratic method.

I really do think it's important to give thought to HOW to give help.

Especially in the technical communities, there's such an over-emphasis in "asking correctly". It perhaps started with usenet (think Eric S Raymond's INSUFFERABLE FAQ on "How To Ask Questions The Smart Way"), and ended with the persnickety and now thankfully moribund stackoverflow gameified and toxic question-and-answer forum.


bro wtf. thanks. this letter is so real.I was thinking about how many times he had to reread to make it perfect .


> ...it's massively expensive to buy the components piecemeal.

I think the point of this is not to make "a product". It's just a fun project that you can build yourself or participate in some way with it's creation and/or funding.

It's not practical. That's OK.


Motto's, slogans, mission statements...

All of these things are 100% bullshit and always have been. It's tragic that Google actually had people believing them when they championed "don't be evil".


The slogan originated in Eng, and was honest at the time, and for many years after.

It obviously got promoted by marketing for external consumption as well.


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

Search: