It definitely has things in common with meetup.com. But it looks meaningfully distinct to me because the appear to specifically have some kind of strong preference against connected devices. Honestly, I've been wishing for things in this vein recently because of the feeling that our world is growing too superficial with our faces buried in phones and being fed by addictive algorithms.
That being said, I think you're right about some of the challenges that an effort like this will encounter.
As a professional haskeller, I feel it necessary to point out for people in this thread who are less exposed to Haskell and who may be Haskell-curious...this is not what real-world commercial Haskell code looks like. To use a C analogy, I'd say it's closer to IOCCC entries than Linux kernel code.
Thanks for that. Having read the article, I was left with the overwhelming impression that I'd have solved it in a totally different way if I was trying in OCaml.
Briefly, I'd have started with an array which for each colour had an array containing the coordinate pairs for that colour. I'd probably then have sorted by length of each array. The state also has an empty array for the coordinates of each placed queen.
To solve, I'd take the head array as my candidates, and the remaining array of arrays as the next search space. For each candidate, I'd remove that coordinate and anything that was a queen move from it from the remaining arrays, and recursively solve that. If filtering out a candidate coordinate results in an empty list for any of the remaining arrays, you know that you've generated an invalid solution and can backtrack.
At no point would I actually have a representation of the board. That feels very imperative rather than functional to me.
To me, this solution immediately jumps out from the example - one of the queens in on a colour with only 1 square, so it HAS to be there. Placing that there immediately rules out one of the choices in both colours with 2 squares, so their positions are known immediately. From that point, the other 2 large regions have also been reduced to a single candidate each.
Yeah, comparing to how you'd solve this in any other mainstream language is really an apples-to-oranges comparison here because this is explicitly tackling the contrived problem of solving it at the type level rather than at the much more common value level. Very few languages in existence have the ability to do this kind of type-level computation. I'd say Haskell is really the only language that could conceivably be called "viable for mainstream use" that currently supports it, and even in Haskell's case the support is new, largely experimental, in a state of active research, and not well integrated with the ergonomics of the rest of the language.
As someone who has never touched Haskell and who knows nearly nothing about it, Haskell is not, in fact, a "dynamically typed, interpreted language", which, "has no currying".
At the risk of explaining away a perfectly good joke, that person is writing programs at the type level. The joke is that the type system is turing complete if you enable the right extensions.
I would argue that the title is misleading and overly alarmist here. This particular bug may have involved recursion and a stack overflow, but that's like saying "malloc kills" in the title of an article about a heap overflow bug. The existence of stack overflow bugs does not imply that recursion is bad any more than the existence of heap overflow bugs implies that malloc is bad. Recursion and malloc are tools that both have pretty well understood resource limitations, and one must take those limitations into account when employing those tools.
Did you see the article references [1][2] from 2006 and 2017 that already argue that recursion is a security problem? It's not new just not well-known.
>> I would argue that the title is misleading and overly alarmist here. This particular bug may have involved recursion and a stack overflow, but that's like saying "malloc kills" in the title of an article about a heap overflow bug.
Let's see what the article[1] you cited says:
Rule 3: Do not use dynamic memory allocation after initialization.
Rationale: This rule appears in most coding guidelines for safety-critical software. The reason is simple: Memory allocators, such as malloc, and garbage collectors often have unpredictable behavior that can significantly impact performance.
If you think recursion is a known security problem, do you also think using the heap is a known security problem?
Arguably, Stack Clash is just a compiler bug--recursive code shouldn't be able to jump the guard pages. This was fixed in Clang in 2021 [1], in GCC even earlier, and in MSVC earlier than that.
Recursion per se isn't an issue; unbounded stack use is. If you either know your input size is bounded (e.g. it's not user-generated) or use tail-recursion (which should get compiled to a loop), it's fine.
If your algorithm does unbounded heap allocations instead, you're still going to get oomkilled. The actual vulnerability is not enforcing request resource limits. Things like xml bombs can then exacerbate this by expanding a highly compressed request (so a small amount of attacker work can generate a large amount of receiver work).
Exactly. The article would have been much more informative if it had detailed why the usual approaches to limiting resource usage wouldn't work to prevent DoS here.
The problem, in practice, is the limit for malloc on most systems is a few GB, while the default stack size on windows is 1MB, a stupidly small size.
I love recursion, so I will spawn a thread to do it in with a decent sized stack, but it’s very easy to break if you use defaults, and the defaults are configured differently in every OS.
Parsing anything from a potential adversary needs to account for failure. Unbounded recursion is secure (ie fails safely) if the compiler is working properly.
As to DoS, without looking at the code I'm unclear why various approaches to bounding resource consumption wouldn't have worked. I assume something specific to this library and how it is used must have prevented the obvious approaches. Still, not an issue in the general case.
Guarding against unbounded recursion requires both compiler support and runtime environment support: you have to use enough resources to handle legitimate queries, but small enough memory constraints that a "query of death" doesn't kill nodes that are expensive to reactivate. Even then, by their very nature queries-of-death are usually hard to detect and a much simpler solution is something you can do in the static space, such as put an arbitrary hard-bound on recursion depth far below your resource constraints so you can fail the query without losing the whole processing node.
Google protobuffers have buried deep within at least their C++ parser an arbitrary hard limit for nesting depth (I think it may be 32). It's annoying when you hit it, but it's there for a reason.
> Guarding against unbounded recursion requires both compiler support and runtime environment support
I feel like this is similar in spirit to saying "guarding against infinite loops requires both ...".
Where resource consumption is concerned, as you pointed out you can track that manually. Presumably you have to do that anyway, since the iterative case will also need to give up and fail the task at some point.
I really don't see where recursion itself introduces an issue here. I guess if you expect to pass through a great many nodes that don't otherwise trigger resource allocation except for the stack frame, and the compiler can't optimize the activation records away, it could be problematic. That's pretty specific though. Is that really the case for a typical parser?
The stack frame also holds local variables. It's not just a return address. If your function requires 3 local variables then each call requires 3 stack slots.
My default uninformed assumption would be that Google is paying Mozilla for making Google the default search engine for Firefox. Does anyone know if this is the case, and if so, what the likely magnitudes are? Because it seems like Google can throw quantities of money at Mozilla that would easily overwhelm whatever pressure this petition might put on them.
Yes, this is correct. Google pays Mozilla hundreds of millions of dollars annually to be the default search engine. This makes up the vast majority of Mozilla Corporation's revenue. It's somewhere in the ballpark of 85% of all their annual revenue last I heard.
They've tried hard in recent years to get out from under Google by diversifying into other areas. For example, they have a VPN service that is a wrapper around Mullvad, and they've made some privacy tools that you can pay to use, also largely wrappers around other companies' tools.
I was an employee of Mozilla Corporation and saw first-hand the effort they were making. In my opinion, it's been a pretty abysmal failure so far. Pulling Google funding would effectively hamstring Mozilla Corp.
If you've made any kind of DNS entries involving this subdomain, then congratulations, you've notified the world of its existence. There are tools out there that leverage this information and let you get all the subdomains for a domain. Here's the first one I found in a quick search:
There's a spectrum of efficiency/redundancy choices an organization can make. On one (theoretical) end of the spectrum the organization maximally leverages each individual's unique skills/knowledge. This is the most efficient part of the spectrum. On the other end every person is an interchangeable cog. This is the most resilient but also least efficient part of the spectrum. Small organizations usually skew much more to the efficiency end of the spectrum because they typically have significant resource constraints. As an organization grows, more people depend on its existence, and my observation has been that resilience and self preservation typically become more important than efficiency. This phenomenon is not unique to governments, it happens in all kinds of organizations.
I have a question for all the LLM and LLM-detection researchers out there. Wikipedia says that the Turing test "is a test of a machine's ability to exhibit intelligent behaviour equivalent to, or indistinguishable from, that of a human."
Three things seem to be in conflict here:
1. This definition of intelligence...i.e. "behavior indistinguishable from a human"
2. The idea that LLMs are artificial intelligence
3. The idea that we can detect if something is generated by an LLM
This feels to me like one of those trilemmas, where only two of the three can be true. Or, if we take #1 as an axiom, then it seems like the extent to which we can detect when things are generated by an LLM would imply that the LLM is not a "true" artificial intelligence. Can anyone deeply familiar with the space comment on my reasoning here? I'm particularly interested in thoughts from people actually working on LLM detection. Do you think that LLM-detection is technically feasible? If so, do you think that implies that they're not "true" AI (for whatever definition of "true" you think makes sense)?
> 3. The idea that we can detect if something is generated by an LLM
The idea behind watermarking (the topic of the paper) is that the output of the LLM is specially marked in some way at the time of generation, by the LLM service. Afterwards, any text can be checked for the presence of the watermark. In this case, detect if something is generated by an LLM means checking for the presence of the watermark. This all works if the watermark is robust.
The original Turing test started by imagining you're trying to work out which of two people is a man or woman based on their responses to questions alone.
But supposing that you ran that test where one of the hidden people is a confederate that steganographically embeds a gender marker without it being obvious to anyone but yourself. You would be able to break the game, even if your confederate was perfectly mimicking the other gender.
That is to say, embedding a secret recognition code into a stream of responses works on humans, too, so it doesn't say anything about computer intelligence.
And for that matter, passing the Turing test is supposed to be sufficient for proving that something is intelligent, not necessary. You could imagine all sorts of deeply inhuman but intelligent systems that completely fail the Turing test. In Blade Runner, we aren't supposed to conclude that failing the Voight-Kampff test makes the androids mindless automatons, even if that's what humans in the movie think.
I think measuring intelligence in isolation is misguided, it should always be measured in context. Both the social context and the problem context. This removes a lot of mystique and unfortunately doesn't make for heated debates.
In its essentialist form it's impossible to define, but in context it is nothing but skilled search for solutions. And because most problems are more than one can handle, it's a social process.
Can you measure the value of a word in isolation from language? In the same way you can't meaningfully measure intelligence in a vacuum. You get a very narrow representation of it.
Google search is completely broken IMO. I stopped using Google search years ago and every time I go back on the off chance that it's bigger index has something that DuckDuckGo couldn't find for me.
Image search isn't great either but it still often gives me something close and that usually satisfies my image searching needs.
I still find YouTube recommendations quite good for me, but there are occasional ones I've watched already. I still go down its fun (and educational!) rabbit holes all the time.
Exact same experience, YouTube recommendations (in incognito without being logged in!) usually give me stuff related to the video in watching.
However when they don't, it's invariably to push some alt-right slop down my throat. Video is about a comedian? Suggestion "feminist woke takedown compilation". Video about news? Suggestion "$european_far_right_party's channel says gypsies are subhuman". Video about economics? Suggestion is Jordan Peterson ranting about something. And so on and so on. It's pretty tiring.
I think the fundamental approach being taken by this project is immensely valuable to the world. This kind of education about open standards might actually be the most powerful tool that can help us take steps in the direction away from giant opaque corporations and back towards the systems based on open standards that the internet originated from. I really hope this project continues to be updated and get more and more eyes and contributors. If you feel the same way, I'd say at least throw it a GitHub star. https://github.com/blakewatson/htmlforpeople
(Note: I have nothing to do with this project thus far and have nothing to gain from saying this.)
HTML for People is waaaay more approachable than this. My wife could follow the HTML for People tutorial. It shows you how to create a real web page in a real browser without first bogging you down in coding details.
The MDN tutorial is talking about img alt attributes before you even create a single .html file! That's how to put people off.
As a technical person who recently taught myself frontend from scratch, I found https://web.dev/learn way more structured and thorough. The CSS lesson covers all the essentials and actually made me enjoy working with CSS.
web.dev doesn't get as much love as MDN, but it totally should!
That’s the website my high school used in engineering sciences classes to give students an introduction to HTML. I don’t see the point of your comment (I think it’s sarcasm, but I’m not even sure), can you be a little bit more constructive?
The point may be that OP's guide is not meant for high school/engineering students, it is meant for everyone. MDN's "introductory" sections have too many big words to be of use to laypeople.
I really hope so too. I really wonder what would happen if there was an alternative like... instead of spending X dozen hours learning how to use WordPress, or MS Word for that matter, people (in the general population) felt like spending those X dozen hours learning HTML was a viable and useful alternative to achieving their goals!
Will you add on to it to include custom CSS, or maybe a section for using different CSS templates (and where to find them), to make a slightly larger website like your own (blakewatson.com)?
No I think I will probably keep it focused on HTML. I think my "CSS basics" chapter is as far as I want to go with styling. But I would love to see other folks publish easy-to-understand CSS tutorials.
::backdrop was useful to me. Right now I am learning the last two years of stuff, refreshing my frontend skills. Things like scoping are a dream come true.
I haven't got all the way through it, but seeing the contents drop-down made me feel at home.
I put document structure first so the content looks good with no styling and no class attributes. I use no divs, just the more sensible elements. Sections, Articles, Asides and Navs work for me. There should be headings at the start of these elements, optionally in a Header and optionally ending with a Footer. The main structure is Header - Main - Footer.
Really there should be a need to keep it simple, and that begins with the document structure. It is then possible with scoping to style the elements within a block without having to use any classes except for at the top of a block.
It infuriates me that we have gone the other way to make everything more and more complex. We have turned something everyone should be able to work with into an outsourced cottage industry. Nowadays the tool chain needed for frontend development is stupid and a true barrier to entry. Whenever you look under the hood there is nothing but bloat.
My approach requires strict adherence to a document structure, however, my HTML content is fully human readable and the content looks great without a stylesheet, albeit HTML 1.0 pre-Netscape looking.
Tim Berners Lee did not have class attributes in HTML 1.0 but he did want content sectioning. Now that there is CSS grid it is easy to style up a structured document. However, 'sea of divs' HTML requires 'display: contents' to massage the simplest of form to fit into a grid.
I feel that a guide is needed for experienced frontend developers that are still churning out 'sea of div' content. In the Mozilla guide for 'div' it says that it is the element of last resort. I never need the 'div' because there is always something better.
The CSS compilers are also redundant when working with scoping and structured content. Sadly my IDE is out of date so I have to put the scoping in at the end as it does not recognise @scope. Time to upgrade...
Anyway, brilliant guide, in the right direction and of great interest to me and my peculiar way of writing super neat content and styling.
That being said, I think you're right about some of the challenges that an effort like this will encounter.