So you have to make sure to compile only in release mode just to get to 16 bits.

This has interesting applications. For example, you can exploit this with dilute metal vapor in an expanding helium gas to cool the metal vapor to very low temperature - the Joule-Thomson expansion of helium increases the helium's temperature by converting the energy of the intermolecular forces into heat. This draws out energy from the metal vapor. If done in a vacuum chamber, then in the region before the shockwave formed by the helium, the supercooled metal atoms will form small van der Waals clusters that can be spectroscopically probed in the jet. This was an interesting area of study back in the 80s that advanced our understanding of van der Waals forces.

"To ensure the long-term sustainability of this project, use of the WiX Toolset requires an Open Source Maintenance Fee. While the source code is freely available under the terms of the LICENSE, all other aspects of the project--including opening or commenting on issues, participating in discussions and downloading releases--require adherence to the Maintenance Fee.

In short, if you use this project to generate revenue, the Open Source Maintenance Fee is required."

I'll give the benefit of the doubt and assume this is just a difficult concept to succinctly explain in a short paragraph. But that summary - that revenue-generating use requires payment - feels misleading to me. Under their license, nothing stops me from creating my own build from source and using it per the terms of the MS-RL license, including for commercial purposes. So to me it feels like a scare tactic to coerce commercial users into becoming sponsors for the project.

I certainly understand the challenges faced by open source maintainers today, but the specific approach taken here just doesn't feel ethical to me. I ended up passing on WiX for that reason even though I'm not a commercial user.

I know you are saying it isn't clear, but your quote literally includes the statement "While the source code is freely available under the terms of the LICENSE".

"In short, if you use this project to generate revenue, the Open Source Maintenance Fee is required."

Perhaps I'm being too semantic, but I don't feel that is an accurate representation of the license terms involved here.

I guess it's treating 'if you are generating revenue and need support you're gonna be demanding as hell' as implicit?

This is pushing those enterprise customers that are just using and updating binary releases because they don't want to take on the compliance risks of first-party support to pay for official versions.

"""

Sign up for GitHub Sponsorship and create the tiers: Small organization (< 20 people): $10/mo Medium organization (20-100 people): $40/mo Large organization (> 100 people): $60/mo

"""

You are beyond 'cash strapped' if $10/month for something as fundamental as this breaks the bank. The fully loaded cost of a single US software developer is already above $100/hour.

If you’re a founder doing your own finances, well every additional little monthly charge even if it’s just $1 is quite annoying:

Filing and reconciling 12 receipts takes say 1 hour per year, what if you’re using 20 dependencies? That’s an extra 3-5 days per annum of admin.

So in the name of promoting basic numeracy, and taking into account the realities of scale. Matching that cost for those dependencies (this is a >100 person company) would be $560k per month. That gets you minimal support, just a guarantee that you can submit issues. No guaranteed security maintenance, compliance, or governance of the project.

You can spin up a very strong developer team for forking and maintaining an internal copy of opensource projects at that cost and a lot of large companies do just that. Should they contribute those changes back? Sure if that made sense.

A lot of time in my experience that internal copy is stripped to the bones of functionality to remove the surface area of vulnerabilities if the useful piece isn't extracted into the larger body of code directly. It's less functional with major changes specific to that environment. Would the upstream accept that massive gutting? Probably not. Could the company publish their minimal version? Sure but there are costs there as well and you DO have to justify that time and cost.

Would a company in-house the support and development of a tool over $40/month? Absolutely not, for a one-off case that's probably fine. If you want to meaningfully address the compensation issue from enterprises, opensource single-project subscriptions aren't going to be the answer.

I would LOVE to see more developer incentive programs, but one-by-one options aren't scalable and most projects don't want to provide the table-stakes level of support required of any vendor they work with. It's not optional for those organizations, its law and private contracts.

For example, IIRC, GitHub (all of GitHub) calculated they had 660 direct dependencies. That's still a lot but it's not 9400. :)

WiX is just the first project to use the OSMF because I need a project to "debug" an issues in OSMF system. As we get all the issues resolved, we may see the OSMF be adopted widely... or not.

To be pedantic, it can be $0 if the developer is you yourself, or your friends, wives, husbands and other relatives.

Mind you, I never implied that there are thousands or hundreds of such cases. But there are some.

If more consumers choose to take on the work of maintaining their own fork because of the OSMF, that's okay too. I believe we are more likely to get contributions if more developers are in the code instead of just consuming binary builds. That's another small reason why I believe the OSMF can work.

Here is their sponsorship page: https://github.com/sponsors/wixtoolset

It is challenging to describe the concept succinctly, especially as there are lots of varied expectations people have about how Open Source projects work. I'm definitely open to suggestions on how to improve the text.

feels like a pay to interect iff one of the parties interacting is a profit making entity

Listen, I run Debian too. But I'm not going to get online and complain out X Y Z not working when I'm running a package from 3 years ago. Please, be for real.

No, it's stable, it's reliable, it's the solution to all of the problems I had on Arch, Fedora, and other rolling releases.

And again, Nvidia drivers work perfectly right out of the box on X11.

Wayland? That's a new problem.

We're talking about very new developments here. You're running years old packages. Okay? That's not going to work.

When you're running Debian, it's expected you're going to be 3-5 years behind the Linux userspace status quo. So it's absolutely fine you're on X11. I have a desktop on Bookworm running X11 on Nvidia - works great, I love it. I also have a very, very new laptop running Tumbleweed on Wayland and kernel 6.15. X really struggles with new hardware in a way Wayland does not. For me on that computer, Wayland is better in a plethora of ways. I am a bit forced to run a very new kernel and Mesa and all that due to running bleeding edge hardware.

One thing I've found I enjoy is working on a larger-scope toy project composed of many loosely coupled systems. It works well for me because no matter what type of project I'm interested in working on, I can usually find something applicable within the larger project. Currently on my to-do list are behavior trees and procedural terrain generation, and honestly I don't know how I'm going to decide which to do first.

And those were THE best vector art tools, because when you drew a shape and the shape overlapped with another, it automatically erased the other shape like you would expect it to in a raster graphics editor. In pretty much every other software I tried, e.g. Inkscape, Affinity, Corel Draw, Illustrator, you just get two separate shape objects one on top of the other. They seem to be designed for drawing the outlines, not to actually paint with brushes. Flash understood what was intuitive for artists.

Honestly, the older I get the stranger I feel about the fact that there was a brilliance in creating interface for people to be productive with back then that seems to be completely gone. I think this may be in part because desktop applications are unusual nowadays, but it's just really strange that the things I remember seeing have been done exactly once and never copied by anybody despite how well they worked.

It's also worth noting that the interface is clean in such a way that it is straightforward to automatically generate bindings. In my case, I used a handful of Roslyn Incremental Source Generators to automatically generate bindings between C# and Lua that matched my overall architecture. It was not at all difficult because of the way the interface is designed. The Lua stack together with its dynamic typing and "tables" made it very easy to generate marshallers for arbitrary data classes between C# and Lua.

That said, there are plenty of valid criticisms of the language itself (sorry, not to nitpick, but I am really not a fan of one-based indexing). I'm thinking about designing an embedded scripting language that addresses some of these issues while having a similar interface for integration... Would make for a fun side project one of these days.

It is very funny how this is just the one sole criticism that always gets brought up. Not that other problems don't exist, but they're not very talked about.

Lua's strength as a language is that it does a lot quite well in ways that aren't noticeable. But when you compare things to the competition then they're quite obvious.

E.g. Type Coercion. Complete shitshow in lots of languages. Nightmare in Javascript. In Lua? It's quite elegant but most interestingly, effortlessly elegant. Very little of the rest of the language had to change to accomodate the improvement. (Excercise for the reader: Spot the one change that completely fixes string<->number conversion)

Makes Brendan Eich look like a total clown in comparison.

Eventually you end up in a place where it's beneficial to have converter functions that show up in the call stack frames so that you can keep track of whether the index is in the right "coordinate index system" (for lack of a better term) for the right language.

One can read through “mystdlib” part of any meaningful Lua-based project to see it. Things you’ll likely find there are: NIL, poor man’s classes, __newindex proxying wrapper, strict(), empty dict literal for json, “fixed” iteration protocols.

You don’t even have to walk too far, it’s all right there in neovim: https://neovim.io/doc/user/lua.html

Why numbering should start at zero. -- Dijkstra

To me 1 based indexing is natural if you stop pretending that arrays are pointers + index arithmetics. Especially with slicing syntax.

It's one of the things that irked me when switching to Julia from Python but which became just obviously better after I made the switch.

E.g. in Julia `1:3` represents the numbers 1 to 3. `A[1]` is the first element of the array, `A[1:3]` is a slice containing the first to third element. `A[1:3]` and `A[4:end]` partitions the array. (As an aside: `For i in 1:3` gives the number 1, 2, 3.)

The same sentence in python:

`1:3` doesn't make sense on its own. `A[0]` is the first element of the array. `A[0:3]` gives the elements `A[0], A[1]` and `A[2]`. `A[0:3]` and `A[3:]` slice the array.

For Python, which follows Dijkstra for its Slice delimiters, I need to draw a picture for beginners (I feel like the numpy documentation used to have this picture, but not anymore). The Julia option requires you to sometimes type an extra +1 but it's a meaningful +1 ("start at the next element") and even beginners never get this wrong.

That said, it seems to me that for Lua, with the focus on embedding in the C world, 0 index makes more sense.

"when starting with subscript 1, the subscript range 1 ≤ i < N+1; starting with 0, however, gives the nicer range 0 ≤ i < N"

So it's "nicer", ok! Lua has a numeric for..loop, which doesn't require this kind of range syntax. Looping is x,y,step where x and y are inclusive in the range, i.e. Dijkstra's option (b). Dijkstra doesn't like this because iterating the empty set is awkward. But it's far more natural (if you aren't already used to languages from the 0-indexed lineage) to simply specify the lower and upper bounds of your search.

I actually work a lot with Lua, all the time, alongside other 0-indexed languages such as C and JS. I believe 0 makes sense in C, where arrays are pointers and the subscript is actually an offset. That still doesn't make the 1st item the 0th item.

Between this, and the fact that, regardless of language, I find myself having to add or subtract 1 frequently in different scenarios, I think it's less of a deal than people make it out to be.

If you then even consider the simple case of nested arrays, I think it becomes really difficult to defend 1-based indexing as being cognitively easier to manipulate, as the unit of "index" doesn't naturally map to a counting number like that... if you use 0-based indexes, all of the math is simple, whereas with 1-based you have to rebalance your 1s depending on "how many" indexes your compound unit now represents.

If the word for word same argument was made by an anonymous blogger no one would even consider citing this as a definitive argument that ends the discussion.

  t={}
  t[#t+1] --> t[1] DONE!
  t[#t==0 and 0 or #t+1]

This is also true in awk as well, nobody ever whines about awk "arrays" being 0

The real gripes should be globals by default and ... nothing. Lua is wonderful.

I get you are taking the piss but ~= is just as logical as != being the symbols for: "not equals", if you've been exposed to some math(s) as well as ... well, ! means factorial, doesn't it?

Syntax is syntax and so is vocabulary! In the end you copy and paste off of Stack Exchange and all is golden 8)

  [attr~=value]
  Represents elements with an attribute name of attr whose value is a whitespace-separated list of words, one of which is exactly value.

I'm a big fan of Lua, including for the reasons you mention. I suspect the reason this one thing is always brought up is twofold: it's easy to notice, and it's very rare these days outside of Lua (if you consider VB.NET to be a legacy language, anyway). Other criticisms take more effort to communicate, and you can throw a rock and hit ten other languages with the same or similar issues.

To be fair, Brendan Eich was making a scripting language for the 90's web. It isn't his fault Silicon Valley decided that language needed to become the Ur-language to replace all application development in the future.

IIRC, Eich was quite influenced by Python's design. I wish he'd just used Lua - would likely have saved a lot of pain. (Although, all that said, I have no idea what Lua looked like in 1994, and how much of its design has changed since then.)

If you don't know what Lua was like then, don't wish that I'd "just used Lua".

Other issues include Netscape target system support, "make it look like Java" orders from above, without which it wouldn't have happened, and more.

It sounds like you're saying Yoz got the sequence of events wrong, and that MILLJ was a necessary part of getting scripting in the browser? I sort of had the impression that the reason they hired you in the first place was that they wanted scripting in the browser, but I wasn't there.

I don't think Lua was designed to enforce a security boundary between the user and the programmer, which was a pretty unusual requirement, and very tricky to retrofit. However, contrary to what you say in that comment, I don't think Lua's target system support or evolutionary path would have been a problem. The Lua runtime wasn't (and isn't) OS-dependent, and it didn't evolve rapidly.

But finding that out would have taken time, and time was extremely precious right then. Also, Lua wasn't open-source yet. (See https://compilers.iecc.com/comparch/article/94-07-051.) And it didn't look like Java. So Lua had two fatal flaws, even apart from the opportunity cost of digging into it to see if it was suitable. Three if you count the security role thing.

Yes, the Sun/Netscape Java deal included MILLJ orders from on high, and thereby wrecked any Scheme, HyperTalk, Logo, or Self syntax for what became JS.

Lua differed a lot (so did Python) back in 1995. Any existing language, ignoring the security probs, would be flash-frozen and (at best) slowly and spasmodically updated by something like the ECMA TC39 TG1 group, a perma-fork from 1995 on.

Flash-freezing Lua might not have been so bad; that's basically what every project using Lua does anyway. And by 01995 it was open source.

In case anyone is interested, here's a test function from the Lua 2.1 release (February 01995):

    function savevar (n,v)
     if v == nil then return end;
     if type(v) == "number" then print(n.."="..v) return end
     if type(v) == "string" then print(n.."='"..v.."'") return end
     if type(v) == "table" then
       if v.__visited__ ~= nil then
         print(n .. "=" .. v.__visited__);
       else
        print(n.."=@()")
        v.__visited__ = n;
        local r,f;
        r,f = next(v,nil);
        while r ~= nil do
          if r ~= "__visited__" then
            if type(r) == 'string' then
              savevar(n.."['"..r.."']",f)
            else
              savevar(n.."["..r.."]",f)
            end
          end
          r,f = next(v,r)
        end
       end
     end
    end

The Lua version history https://www.lua.org/versions.html gives some indication of what a hypothetical Sketnape Inc. would have been missing out on by embedding Lua instead of JavaScript. Did JavaScript have lexical scoping with full (implicit) closures from the beginning? Because I remember being very pleasantly surprised to discover that it did when I tried it in 02000, and Lua didn't get that feature until Lua 5.0 in 02003.

Which remains one of the most baffling decisions of all time, even to this day. Javascript is unpleasant to work with in the browser, the place it was designed for. It is utterly beyond me why anyone would go out of their way to use it in contexts where there are countless better languages available for the job. At least in the browser you pretty much have to use JS, so there's a good reason to tolerate it. Not so outside of the browser.

The pressure to evolve JS in a more fair-play standards setting rose and fell as browser competition rose and fell, because browser vendors compete for developers as lead users and promoters. Before competition came back, a leading or upstart browser could and did innovate ahead of the last JS standard. IE did this with DHTML mostly outside the core language, which MS helped standardize at the same time. I did it in Mozilla's engine in the late '90s, implementing things that made it into ES3, ES5, and ES6 (Array extras, getters and setters, more).

But the evolutionary regime everyone operated in didn't "decide" anything. There was and is no "Silicon Valley" entity calling such shots.

Companies including Bloomberg and Microsoft (neither in or a part of Silicon Valley), also big to small companies all over the world, built on JS once Moore’s Law and browser tech combined to make Oddpost, and then gmail, feasible.

While the Web 2.0 foundations were being laid by indie devs, Yahoo!, Google, others in and out of the valley, most valley bigcos were building “RIAs” on Java, then Flash. JS did not get some valley-wide endorsement early or all at once.

While there was no command economy leader or bureaucracy to dictate “JS got on first but it is better to replace it with [VBScript, likeliest candidate]”, Microsoft did try a two-step approach after reacting to and the reverse-engineering JS as “JScript”.

They also created VBS alongside JS, worked to promote it too (its most used sites were MS sites), but JS got on first, so MS was too late even by IE3 era, and IE3 was not competitive vs. Netscape or tied to Windows. IE4 was better than Netscape 3 or tardy, buggy 4 on Windows; and most important, it was tied. For this tying, MS was convicted in _U.S. v. Microsoft_ of abusing its OS monopoly.

Think of JS as evolution in action. A 2024-era fable about the Silly Valley cartel picking JS early or coherently may make you feel good, but it’s false.

https://xkcd.com/927/

;)

I'm not totally sold on embrace-extemd-extinguish here, but learning about this case was eyebrow raising for me.

C# DevKit is however based on VS license. It builds on top of base C# extension, the core features like debugger, language server, auto-complete and auto-fixers integration, etc. are in the base extension.