Which smart TVs natively support port knocking?
469 karma · joined November 28, 2023
If you're using the Ruroco client to proxy requests to the server, then you could do the same with WireGuard. You could have HAProxy (or something similar) proxy requests from your local network to the WireGuard interface.
You can definitely run an HTTP server behind WireGuard. WireGuard just adds a network interface that your server can listen on (e.g. your server would listen on a private address like 10.0.0.1).
I'll accept that there are some intelligent developers out there that are more productive without static type checking, but I personally don't understand it. If you don't have a tool analyzing your program's types, then your brain becomes the type checker. I personally would much rather focus on higher level problems. I don't even see type checking and code formatting as human level concerns anymore, and would rather have my computer do it for me, but I guess it's just a preference. Do whatever works for you.
The idea that Microsoft was attempting to turn JS into an object oriented C# clone was a very common objection in the early days of TS (especially since one of the lead developers on the project is also the primary architect of C#). That objection ended up being completely false. TS aims to type check the full gamut of existing JS, and embraces all of the language's quirks and idioms. There are people doing serious functional programming in TS with libraries like fp-ts and effect (which is basically the TS version of Scala's Zio). If this is your primary objection I would give TS a second look.
You could paraphrase that as: core utilities that ship with my operating system should obviously be more reliable than random code fetched from the internet.
> For the comparison to be valid
I was responding to the limited scope of your statement "Yet, they are still a lot bigger than most micro-libraries. And more complex." Utilities like `yes` and `true` are neither big nor complex. The man pages are longer than the source code necessary to replace them.
I get how it works, it just feels like a hack designed to work around a missing feature, rather than the ideal way to handle the problem. Phrased another way: if the scripting media query was ubiquitous I would never go back to toggling classes via JS.
> Another factor may have been IE;
Browsers have been shipping features that don't work in IE for the better part of the last decade. If you think CSS nesting would break IE, imagine what IE would do when it encounters a modern JS feature that can't be polyfilled like Proxies.
Some of them are incredibly trivial. I made this exact same comment months ago, but the yes command is basically a one line bash function [1]:
function yes { while true; do echo "${1:-y}"; done }
If your styles are defined within external stylesheets, then having to extract them from their respective stylesheets and place them directly in a noscript DOM node is not very ergonomic (and it will also affect your ability to cache those styles, since they're now a part of your potentially dynamically generated HTML rather than a static stylesheet).
> use JavaScript itself to add or remove a class that is used within the relevant selectors.
Well yeah, If you're ok with adding JS then most native CSS features can be polyfilled. This is a very imperative solution to a problem that the scripting media query handles declaratively. I would much rather have my styles dictated by my stylesheets, and reserve my JS for adding interactivity.
> However, even if someone figured out how to implement it twenty years ago, it probably still couldn't have been used for performance reasons.
Yeah the has selector is similar to a lookahead assertion in a regular expression, and CSS nesting is similar to a lookbehind (both of which can be computationally expensive). I'm not sure browsers needed to wait until the 2020s to deliver these features though. I would have loved to ditch SASS and SCSS years ago.
[1] https://caniuse.com/css-has
The construction industry violates more OSHA standards than other industries because it's more tightly regulated by OSHA, which is of course because it's a dangerous industry. This is the equivalent of saying that hedge funds are overrepresented in SEC violations, or oil companies are overrepresented in EPA violations. It's almost a tautology.
I don't think frivolity is necessarily binary — it's more of a spectrum. On one end of the spectrum you have tunnels that connect landmasses separated by massive bodies of water, and allow emergency services to operate efficiently (where the only alternative is a giant suspension bridge).
On the other end of the spectrum you have tunnels such as the LVCC Loop which help convention goers and tourists avoid what is effectively a brisk walk or bike ride (this is also largely a glorified Tesla marketing campaign).
> just like many other construction companies
I'm not sure I believe disfiguring blue collar construction workers is just standard business practice while building a small tunnel just because you posted a link stating that construction can be dangerous. Of course construction as an industry is going to be more dangerous than childcare for instance (and therefore over-represented as an industry in statistics), but that doesn't mean you waive off every accident and chalk it up to a business expense.
If there's another company out there mutilating their workers via chemical burns to shuffle people 1.7 miles around a convention center [1], then I'll gladly bestow upon them the innovator award as well. Stating that constructing things is generally dangerous feels like something out of the PR department at the Boring Company.
[1] https://web.archive.org/web/20240729111337/https://www.borin...
If the reports are to be believed then there was another "innovation" as well: ignoring worker safety [1].
"An investigation by the state OSHA, which Bloomberg Businessweek has obtained via a freedom of information request, describes workers being scarred permanently on their arms and legs [...] In an interview with Businessweek, one of the tunnel workers recalls the feeling of exposure to the chemicals: “You’d be like, ‘Why am I on fire?’”"
[1] https://www.bloomberg.com/news/features/2024-02-26/elon-musk...
If there was a way for users to define their own coeffects then you could sidestep this issue, but I saw this quote in one of the design documents: "Runtime will have a native knowledge of each co-effect. We will not allow co-effects to be defined in user-land code [...] An important aspect to note here is that certain co-effects that need deep support from runtime such as io and pure will need to be implemented in the runtime" [2].
[1] https://docs.hhvm.com/hack/contexts-and-capabilities/availab...
[2] https://github.com/facebook/hhvm/blob/master/hphp/hack/doc/H...
It's possible, but I can't thoroughly evaluate coeffects until they land in a mainstream language with production usage. What I do know from experience is that you can't quietly block the entire thread on a network request in some innocuous looking function in JS. You have to return a promise and then the calling function has the option to await that promise, but I'm sure the academics in their ivory towers have theorized about something better.
This is basically the function coloring problem. There was some ardent discussion about this a few weeks ago on HN [1], where the top comment positioned function coloring as a feature, because it highlights where expensive operations like IO might potentially be happening in your application.
I saw a comment recently where someone pointed out an old API in Java where comparing two URLs for equality initiates a DNS request, and so something as simple as putting a URL in a hash table could end up involving a network request [2]. So maybe it's reasonable to color functions that connect to the network at the very least. If I used a URL comparison library and it returned a promise it would immediately set off alarms in my mind.
* Users have been indoctrinated by years of marketing (e.g. the "there's an app for that" ads).
* Safari hides the "add to home screen button" deep within the share menu, and home screen real estate is incredibly valuable. Native apps have the advantage of Smart Banners [1].
* For several years Webkit didn't support notifications, and as much as I hate annoying notifications, it's undoubtably useful from a business perspective to be able to ping users and remind them to use your application. Even after allowing notifications in Webkit, they made sure to introduce Live Activities which are exclusive to native apps.
Microsoft did exactly that (since they own both NPM and Github) by allowing you to verify the provenance of NPM packages built using Github Actions [1]. It's not required for all packages though. They've also started requiring all "high impact" packages to use two factor authentication [2].
[1] https://github.blog/security/supply-chain-security/introduci...
[2] https://github.blog/changelog/2022-11-01-high-impact-package...
I didn't say FrankenPHP proxies to the PHP dev server. I'm saying FrankenPHP is a Frankenstein amalgamation of the Caddy reverse proxy server and PHP, which is necessitated by the lack of a production server built in to PHP. Some languages/runtimes like Go (which Caddy is written in) and Node have production ready servers built in to their standard libraries.
> I'd reverse proxy to it as a matter of principle [...] some other server should be managing HTTPS.
I've used Caddy and it's great, but if I have Cloudflare or some other service terminating SSL and serving static assets, then I don't necessarily need Apache, Nginx, or Caddy acting as a middleman.
> The security situation with node package dependencies is hilariously bad
Most of the security issues involving NPM are related to client side JS, not server side JS. PHP doesn't run client side at all, so it's a bit of an apples to oranges comparison. If you're just doing traditional server side templating then there are plenty of rock solid frameworks. Hapi has zero third party dependencies and was designed by one of the authors of the OAuth spec for example.
[1] https://www.php.net/manual/en/features.commandline.webserver...
Until you need to perform two or more IO operations at the same time (e.g. more than one of: database query, Redis query, HTTP request, file operation, etc). Then it becomes:
input -> Promise.all (or Promise.race, or Promise.allSettled, or Promise.any) -> output.
If you watch Ryan Dahl's original presentation introducing Node, you'll see that JS was explicitly chosen because of its asynchronous nature — it wasn't shoehorned in: https://youtu.be/EeYvFl7li9E?t=795&si=FG0yxaGoCgz1rqOX
> Not sure what you mean. There are a bunch of ways to run PHP
Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary: https://nodejs.org/docs/latest-v22.x/api/http.html#class-htt...