I agree with you, but I go one step further: I am disappointed by OSM raster tiles and especially Google's digital tiles because even they show barely enough information, if you compare them to old style printed street directories. I think they also have a tendency to avoid crowding by omitting important things in busy spaces and showing useless things in empty spaces, whereas the correct thing to do is to show the important things in the busy spaces precisely to indicate that they're busy spaces. And I think there are better things that can be done than just showing trivia if you consider the local area (e.g. a private tennis court might be better off not shown in especially if there's not a great density of mapped objects, but perhaps it's relevant at a resort).
But that's a lot of work, and whereas it's easy to add extra trivia to OSM it's much harder to add extra detail to tiles.
As Doctor_Fegg has pointed out further down, the OSMF provided raster tile service on openstreetmap.org is primarily intended to provide fast feedback to contributors and not for general purpose use, in particular not as a competitor to google.
The whole point of OSM is that you can take the data and build / design your own things. Yes it would be nice if there were multiple viable google alternatives based on OSM and other open data, but that is likely just a pipe dream, the economics don't really work.
I agree, I also dislike the term SQL injection. But the problem isn't that there is a query, there problem is that the source code of one program is constructed by string manipulation in the source code of another program. XSS issues (where javascript can be embedded into a string that is supposed to be a value in a HTML document) are the same. Also occurs with shell scripts. The goal has to be to avoid such manual processes. Between lower level languages, it's customary to export a function call in a standard ABI. It should also be the same here: regard queries as function calls in a foreign language. Javascript is basically there, but query languages only have fits and starts (e.g. you often have some syntax like `SELECT * FROM "tbl" where "field" = ?` which can then accept the parameter in a form that is intended for transferring user values) and generally rely on good hygiene and ORMs to protect the end user.
Actually both. Our internal closed source projects are only in our GitLab. The open-source stuff is both on GitHub and our GitLab. Since our GitLab instance isn't public we only use the issue tracker on GitHub for public stuff.
It's closer to the truth than you usually get. They're having a bad day, it's completely true. It's the start of my day, but I guess this is the middle of the night for them. There's no such thing as unicorns, but that just highlights the metaphorical nature of the remaining claim - getting Unicorns under control means solving their problems. Normally "professional" corporate speak means avoiding saying anything whose meaning is plain on its face and disconfirmable while avoiding the implication that the company is run and operated by humans. This is a model. (Obviously the came up with the message in advance, which just goes to show that someone in the company is well enough rounded to know that if it is displayed, they're having a bad day.)
Hold for me is pretty good. I've never used the phonetree feature, but I think it's often the case that I don't know which button I need to press: I have to listen to them all first, then decide which one. Commonly I have to listen to the tree twice: once to decide, and once to find out what to click. I'll probably look for the phonetree next time, so I can just read over it and find what I want. I agree it would be much better to preload it, but that might not be plausible due to privacy concerns or legal reasons.
There are probably only ~10,000 phone trees that cover the vast majority of calls in the USA.
If a phone tree is seen by many users and is identical, there is probably no privacy reason not to publish it. Even moreso if the total number of digits typed in quick succession is < 4 (ie. user hasn't entered some password to get in). A human operator could be the final check.
I recently discovered that you can Google "{company} phone number", and in a number of cases it will offer to call, navigate the phone tree, wait on hold, and call you when a customer service agent is on the line. Delta, Allegiant, etc all seem to work.
Isn't it entirely dependent on the airlines, what counts as one itinery? How could I contractually obligate them to something they didn't agree to be contractually obligated to?
(BTW: I've had multiairline itineraries many times. I think a lot of airlines are perfectly happy to do it because they can't fly domestic in that country and the domestic airline doesn't fly international. Also, there have been times when I haven't been able to, and I've been worried about it, and I got to the airport for manual checkin, and they've said "oh, i see you have an ongoing flight to such-and-such, do you want me to check you in for the whole journey?")
Cookie disclaimers are not GDPR. They're also completely optional; you can have a fully functional modern website that stores state in cookies and not put in a cookie banner. Businesses make choices not to do that and we've become stuck at a local suboptimum.
It depends what you store and what you use it for if it touches the gdpr. You can run entire SaaS products profitably (as we do) without gdpr violations while having no cookie or consent banners. Just don't track users or store information you do not strictly need for your saas. Sure there are many more considerations, but this is a basic consideration.
> you can have a fully functional modern website that stores state in cookies and not put in a cookie banner.
Strictly-speaking, notification before cookies are set is required by the 2002 ePrivacy directive (article 5(3)), which includes cookies (and related technologies) under the banner of the 1995 Data Privacy Directive (later superseded by the GDPR).
The intent of the ePrivacy law is clearly not "have a banner that yells about cookies". The intent is that you only set cookies when someone, say, clicks on the Dark Mode toggle, or does something else that sets a cookie, and that when they do that, they know the data privacy implications.
Traditional uses of cookies aren't affected: "Add to basket? (this uses cookies: learn more)" isn't that onerous, nor annoying. It's a pain for our dark mode toggle, but the law was written back in the day, when the expectation was that we could actually customise our user agents.
