Threads for dstelow
-
I’m pretty prejudiced against Javascript, but even I think this is going a little far. I want to make sure that my websites all work without Javascript, and I test with Javascript disabled in my browser, but I don’t think it’s wrong to add some features with progressive enhancement. Minimal and optional Javascript is great, Javascript abolition is unnecessary.
-
Unless the site’s text changed, there’s nothing there about abolishing Javascript.
But I think I can make a case for it. If I enable JavaScript, I’m giving you the ability to do almost anything with the computing power of my laptop. You can mine bitcoin, track my cursor, and try to exploit whatever security holes Doubleclick has left (or built) in my browser.
Maybe you won’t, but I have to trust that you won’t. And I can’t, because we’re strangers. If you were truly trustworthy, would you ask for this kind of access? Especially if your site does nothing that requires it?
-
Maybe don’t read this then https://lobste.rs/s/fdpdlp/grand_unification_web_technologies
-
-
You must have a very difficult time of it in life because interaction with any person or company implies (some degree of) trust. This doesn’t mean you don’t verify occasionally, but you should probably not visit any site you don’t trust. And if you worry about some dev counting mouse move events in your browser, I don’t see how you get anything done…
-
You do realize this very site (lobste.rs) is dedicated to linking to random - or at least unknown - websites, right? We visit sites we don’t trust all the time. What you do trust is the execution environment of the web browser (brought to you by Doubleclick) to protect you from the worst abuses.
The history of web standards is filled with examples of innocuous features that, unexpectedly, turned out to allow people to steal your credentials, harvest your browser history, or track you across many different sites. Browsers consist of hasty patches upon hasty patches to deal with these issues.
Javascript (and its associated API) increase that attack surface a thousandfold.
-
-
-
-
There are good use cases for JavaScript like maps.
There are cases where we could extend HTML but right now JavaScript is fine. I’m thinking about upvote buttons on lobsters for example. We did for videos but they still all use JavaScript on top.
Still, for reading articles, news, or blogs I don’t see the necessity for JavaScript. Some have nice flourishing like theme changes but that should degrade gracefully.
I use the NoScript plugin too have Javascript mostly disabled.
-
-
This is incredible. I wonder if there is a legal effort to produce specs for Wine to have clean-room code.
-
-
-
-
I mean, MS aren’t selling XP any more, while books and songs still have value. I guess the most charitable explanation is that parts of this are still in Windows 10. Still, this angers my inner rms
-
XP is (probably) full of source code that MSFT paid other companies for and used with their permission. Even if they wanted to, they probably can’t release a working source tree of Windows XP without getting permission to do so from the other license holders. And for what? Giving people explicit permission to use a product that they no longer are interested in supporting? It’s all downsides.
Still, this angers my inner rms
I’m pretty sure RMS would see the unauthorized release of proprietary source code as wrong and unethical.
-
I’m pretty sure RMS would see the unauthorized release of proprietary source code as wrong and unethical.
Sorry, but this is my RMS, not yours
Anyway, I don’t care much really, but no-one is asking MS to support anything or give permission.
-
-
I’m pretty sure RMS would see the unauthorized release of proprietary source code as wrong and unethical.
I have my doubts, particularly if the binaries have been released beforehand.
Now, personally, in the case of Windows XP, and considering the amount of computers that depend on it (and were abandoned when Microsoft abandoned XP), I believe the regulator should step in and actually force microsoft to free the source code, in the name of balance of power between Microsoft and its users.
Creator rights and business rights should be protected, but not beyond what’s reasonable. In this situation, the public interest should weight far more, and the government should act thus.
This would be a compromise already, an alternative to forcing Microsoft to maintain Windows XP forever. With the freed source. Windows XP users could pool their money into maintaining XP themselves.
-
-
-
15 years
No, as I actually like the EU green’s proposal regarding copyright terms (5 year, extendable twice to 15yr by registering and paying a fee).
15 years is already plenty, in keeping the original spirit of copyright, which was to give authors a temporary monopoly, in the interest of the public domain.
With excessive copyright terms, the author gets little to no benefit, while the public domain suffers greatly.
-
-
Unfortunately not. And this is easily from 5~10 years ago.
I do not know what their current stance is, nor have I seen much activity in the topic (“copyfight”, pirate parties, etc) in a long time. Which saddens me.
I do however see that the greens still seem to care about the topic.
-
OK, I found something related but UK rather than EU.
-
Yeah, that actually meant “life + 14”:
The vision then goes on to propose “generally shorter copyright terms, with a usual maximum of 14 years”. By this, we mean that rather than the current maximum of 70 years after the creator’s death, it should only be 14 years after their death. Unfortunately, as written, this appears a bit ambiguous and has caused confusion, so it needs clearing up!
-
-
-
-
-
-
-
-
-
While I hate using XML for config files or other human readable documents, I’ve been a big fan of using XML as an RPC serialization format (or as a way to interact with REST APIs). It’s easy to construct through string concatenation, it’s fairly easy to whip up a quick parser, and there’s tons of high quality, fast implementations out there. Along with schematization it makes it fast and easy to send/verify XML payloads.
-
I hate XML plenty but I keep finding myself and people I work with reinventing basic features of XML like comments or namespaces or query languages on top of our JSON configuration files. Or people try to use TOML or YAML which become harder to understand or reason about as the complexity increases.
I don’t have an answer. It’s just an observation. We threw out the baby with the bathwater.
-
Along with schematization it makes it fast and easy to send/verify XML payloads.
This is the big win for me. You can pass a set on XML schemas to any business partner and they can quickly and generically validate the message on any platform. And with facets and comments, the meaning and properties of the message can be conveyed implicitly and in great detail.
-
I really have trouble understanding this. Why use XML for serialization, especially in RPC or anything going over the network? It’s ludicrously inefficient for that (json is, too, but slightly less so). Just do yourself a favor and pick msgpack/cbor/bencode/protobuf/… or anything really that doesn’t require complicated escaping of the payload. If you want something easy to parse, bencode is much easier than XML anyway.
-
In terms of verbosity, transport encoding (gzip or whatever) probably gets rid of most of the difference. The great thing about XML is that a lot has been invested in efficient implementations of encoders and decoders. Theoretically others could be more performant but are they? And there’s a proliferation of different XML codec implementations - do you want a DOM interface or streaming or something that maps to native objects? Being old and popular has a lot of upsides.
-
XML is useful in this case when both of the following are true:
- The sender and receiver are different organizations
- The payload is more like a document than a serialized data structure
In these cases, an XML schema of one sort or another is very useful for keeping both sides “honest.” The encodings you mention are not typically all that extensible, so you wind up versioning your data structures. You do more work up-front with the XML to save yourself some pain as the years drag on. The pain isn’t worth it if your data structures are small and simple. But sometimes you have one or many external parties that want to do data interchange with you, and defining a common schema in XML gives you a lingua franca that is both richer and harder to screw up than IDL-like binary encodings or ad-hoc JSON or its binary analogs.
It may seem like this never happens, but it may be that there is a document-like object being served out piecemeal by a family of nested REST APIs. If the REST calls are almost always performed in a certain order (get the main thing, get the pieces of the thing, get the pieces of the pieces…) then efficiency might be improved by just doing one call to get the complex thing. You might be able to improve the robustness of the handling on both sides by using XML in cases like that because it’s just easier to extend it without changing the shape in a way that will break the existing parsers.
All this said, if I had my druthers, I’d still probably use XML for a new system once or twice a year, versus using REST+JSON on a weekly basis.
-
For REST API’s, I would just use JSON. Sure, the format itself is inefficient, but if you’re using the REST API from inside a web browser (and if you expect other people to use this API, then you ought to be using it yourself) it’s hard to beat the efficiency of having a JSON codec already included.
You might be able to design your server to use HTTP content negotiation to simultaneously support JSON and Msgpack. Their data models are pretty similar.
-
It’s ludicrously inefficient for that (json is, too, but slightly less so). Just do yourself a favor and pick msgpack/cbor/bencode/protobuf/
Have you done any measurements to come to this conclusion? Especially compared to using EXI envelopes. SOAP is standardized and widespread, so you’d need a very good reason to use anything else.
When you get into fields like HPC, where RPC performance actually matters, you don’t actually use any of these formats.
-
Indeed not, I didn’t know about EXI. Is that… a binary encoding for XML?! It seems less inefficient indeed. But also note how a lot of “modern” RPC is done via thrift, gRPC, finagle, etc. all of which rely on underlying binary encodings to be efficient. And even then they try to optimize for variable length integers and 0-copy decoding.
I can’t even articulate my point properly. In big companies using SOAP, I’m sure there’s tons of good tooling around XML. But if you’re not already using it, it seems to have very little appeal for RPC compared to, say, thrift. Thrift will be faster, smaller on the wire, and also comes with a schema.
-
The point is that you need to justify, using actual numbers, why picking anything other that the established standard (SOAP) is a good idea. Not using SOAP smacks of junior dev-ness. SOAP and XML are going to be around way longer than whatever flavour of the month that always crops up in threads like these.
If EXI is not enough, I’m sure someone has figured out how to use ASN.1 with SOAP. This would enable using for example uPER as the wire format.
-
-
-
-
-
The zeitgeist seems to be the pursuit of form over function and style over substance. Maybe the “younger users” are perceived to be attention deficient because so many are? They were made that way by what I call “the culture of the image”. Raised on a diet of spectacle and fast-paced action purveyed by media creators with the ethics of your average meth dealer, it should come as no surprise that their collective attention span has withered on the vine.
TL;DR for this comment: get … off … my … lawn!
-
-
No disrespect to younger people was intended. They should feel far more insulted by the possibility of being patronized with cat videos than by my (somewhat jesting) attempt at social commentary here. On the other hand, the spectacle-mongers should feel the burn.
It is nothing new. I was complaining about the same thing when I was a teenager in the 90s.
-
-
-
-
-
-
Oh, yep I agree that we should maintain backwards compat one way or another (personally I think this involves having some sort of bit you can put in your config to indicate some “initial version of emacs”, so you could have code hand upgrades cleanly).
I guess I just really dislike this stereotype that people care about flashiness. It definitely helps! But there’s actual ergonomics involved and “we want it to be shiny” is often shorthand for “we want features that make things easier to use in general”.
-
-
-
Over the last 40 years since Emacs was initially created the world of computing changed a lot. “Modern” users expect certain conventions that Emacs (or Vim, for that matter) lack. That doesn’t mean those conventions are better or worse, just … different. Even though Emacs hasn’t changed, in a way the learning curve has increased over time.
-
-
It has telemetry as all other products from M$. Also to get git branch in the PS1 you need to install a module… https://github.com/dahlbyk/posh-git
Wow how it got so complicated compared to setting the PS1 in bash?
-
-
dstelow
3 years ago
|
link
| on:
"Almost everything on computers is perceptually slower than it was in 1983"
Even if true (not my recollection), but components and capacity are sooo much better now. I would not even dream of the beautiful display I have in my current XPS 13s back in the 90s.
-
But that’s sort of the point. We have glitchy, laggy, less powerful interfaces despite the shiny hardware.
-
-
dstelow
3 years ago
|
link
| on:
Domino’s takes its case for non-accessible design to the Supreme Court
This will probably be very unpopular but where do you draw the line? What about freedom of expression without a lot of rules and constraints? If I publish a book in print, am I also forced to produce a Braille version, and an audio version as well? Is black ink on white page -only acceptable? Of course it would be nice but what if I cannot afford any additional production costs…
-
-
I don’t think that physical products (like books) are the same as services (ordering pizza).
Other than that, this all sounds nice in theory, but the problem with it is that very quickly you run in to a situation where people have a very hard time using basic services like ordering pizza. Freedom isn’t a one-dimensional metric that can only go “up” or “down”; sometimes increasing freedom in one area for some decreases the freedom for others.
I don’t think that a situation where every website is forced to be strictly compliant with all accessibility standards would be a good thing, but some action to ensure that basic services are accessible doesn’t strike as a bad thing, especially given the state of the “modern” web. Clearly the developers themselves/free market isn’t going to solve it.
-
Forcing business to put money into making their software more accessible for people they clearly do not care about as customers is not defending anyone’s freedoms.
-
What about the freedom of people to fully participate in society?
-
One can participate in that which they are offered participation: Dominos are not offering participation.
-
This all sounds very simplistic to me. What if no pizza stores “offers participation”. Should people just accept that they won’t be able to order pizza?
That is essentially what the Americans with Disabilities Act is about: making sure people aren’t excluded from vast swaths of society by these sort of “deaths by a thousand cuts”. I don’t really care about Domino’s as such, I care about people having to deal with this kind of stuff at every turn of their lives.
As I said in my previous reply, I’m not completely sure where the balance should be, and it’s a good topic for reasonable discussion, but you seem to be in denial that the discussion even exists by simply handwaving away entire positions. That’s not very helpful.
-
I don’t believe in the ADA anyway, but: The app is not the only method of ordering pizza, and Domino’s is not the only pizzeria. With so many alternatives in method and supplier available, I don’t see forcing app accessibility as doing anything but restricting freedom of expression. If Domino’s app was the only method of ordering pizza, maybe it’d be fair enough, but that’s nowhere near the case.
-
-
-
-
-
-
-
I made the mistake of reading the Hacker News comments on this story:
I’m amazed we still use configuration files like that. Why not have some capable programming language (python, javascript) handle the configuration?
-
-
Depending on how well that user knows OpenBSD, this question may in fact be a good one:
Why use a yet another different text format for configuration instead of JSON/XML/YAML/TOML? OpenBSD tools such as pf, OpenSMTPd and the new httpd (others? I’m not familiar enough) actually share the same syntax, so learn one, be comfortable in the others.
Why use a configuration language instead of a programming language? Though Turing-complete languages have proven themselves useful in the configuration of many applications (e.g. Emacs, Xmonad), they can be sometimes overwhelming for non-programmer users and a simpler language actually is a feature.
-
Not really a reply, but I’d like to add to that:
JSON and XML are bad configuration languages. The other two have issues.
a) Comments are inconvenient (XML) or not possible (JSON)
b) Both make the “adding a line” hard - JSON because of its hash syntax that requires “,” after every line except the last, making “growing the config” hard. XML because of its general verbosity.
c) Generic data formats as they are, they often don’t check for options that are not valid, encouraging misconfiguration through typos. (XML as it should be used being an exception)
I like YAML, because it has references, but there are also surprising parts in that language. Also, I find checking of validity hard. Also, there are at least two styles for everything ;). I see why people don’t like it.
I don’t like TOML that much - it has many of the issues mentioned in c) and some of the “there are two ways of writing things”. Also, I have no mental mapping between what I wrote in TOML and the actual configuration key in the software in the end.
-
-
-
No, because older Javascript interpreters don’t support/ignore them, which is why you get this wonky-ass comma-first style that became popular with the node.js crowd.
-
-
-
-
-
Unrelated to the news, but LWN content is nearly impossible to read on a phone…very annoying
I think is mostly because it’s an email. Otherwise, that’s usually OK (not great).
I wonder if they would accept help to fix that.
I think it’d be hard trying to intelligently format a 72-column fixed plain text email into something that isn’t a VT100. It’d probably be easier if it was rich text (or at least designed to reflow) in the first place.
I’m using wallabag to bookmark the content and read on my phone, usually much later. I also think that lwm works ok with Firefox readability view.
Thanks for the suggestion. I will give it a try although I’m using Firefox less frequently these days
Not sure which phone you have but mine is able to display the original article just fine in horizontal mode. Or in either orientation with Firefox reader view.
You can always switch to the desktop version.