Time to play with the new "toys"!
Uncategorized
7
Posts
5
Posters
0
Views
-
Time to play with the new "toys"!
-
Time to play with the new "toys"!
-
@paoloredaelli no, those will run with their own RouterOS
-
Time to play with the new "toys"!
@stefano behold, cardboard boxes 🙀
-
Time to play with the new "toys"!
@stefano Content Warning : geek porn
-
Time to play with the new "toys"!
@stefano have fun :)
-
@stefano have fun :)
@arosano thank you! I already installed two of them. The third one...I broke the cable, so tomorrow...crimping cables!
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@oblomov@sociale.network @ju@nugole.it
Quello che avevo letto io mostrava che il gatto riconosceva tranquillamente il proprio nome e dei vocaboli precisi, tipo "seduto" per un cane, perché con l'elettroencefalogramma osservavano l'attivazione di certe zone, ma poi decideva che fregacazzi e ignorava bellamente lo stimolo.
Gatti.
Adorabili, maledetti e infami gatti
-
@mark @jwz I will stop responding to your posts until you actually go read _in detail_ the two articles of mine I've linked above, since this has all been addressed there and you've obviously either not read them with enough core or are just sealioning, and in either case you're not worth responding to.
-
@oblomov @jwz I don't think this is a realistic way to attack RSS. Mostly because I don't really buy the narrative "Google killed RSS when they removed Reader."
100% of my podcasts are discovered via RSS or Atom updates. It's entirely possible that RSS was just a bad fit for aggregating updates to pages people read (in fact, I'd argue that this very network we're on right now represents a better model for being kept up-to-date on news).
-
if they can implement XSLT in JavaScript, why not just transition their implementation to a JS one, since the excuse they gave for removing XSLT is that the library they were relying on was old an insecure? Heck, they even wrote the JS polyfill, and are now asking everyone who uses XSLT to replace their correct markup to use XSLT with an invalid markup to use the JS polyfill they they need to ship themselves.
Because killing off XSLT and XML with it (RSS epsecially) is the point.
-
@oblomov @jwz Because we can implement XSLT in JavaScript but not the other way around. JavaScript has many, many, many issues, but it's a pretty good example of the "airplane rule" in terms of being the "one really good basket we keep all our eggs in" for security-sandbox purposes.
(Personally, I'd be 100% in favor of maintaining the XSLT APIs but under-the-hood implementing them in JavaScript, though that would still need security consideration since they'd likely be running in privileged context that has access to more state than regular in-page JavaScript. Possibly not necessary; I'm not familiar enough with the XSLT spec to guess off the top of my head).
-
Testing Whether Fast Charging Kills Smartphone Batteries, And Other Myths
> With batteries being such an integral part of smartphones, it’s little wonder that extending the period between charging and battery replacement has led to many theories and outright myths ab…
-
JavaScript is way more complex than XSLT. So why don't we start by getting rid of that if the aim is to make things simpler and easier to implement?
Oh wait, maybe that was never the point of the removal of XSLT.
-
@oblomov @jwz What does "open" mean in this context?
This is one of the tricky bits of the whole argument I haven't been really able to wrap my head around.
"Open" can't mean as in "Possible to build an alternative browser to the Big Engines" in this context because if that were the goal, removal of something as complicated as XSLT in the feature spec would be a step in that direction, not away from it.
