Originally, maths/mathematics meant "things that are taught", like physics meant "natural things" and similarly for other such names.
However, nowadays a word like physics is understood not as "natural things", but as an implicit abbreviation for "the science of natural things". Similarly for mathematics, mechanics, dynamics and so on.
So such nouns are used as singular nouns, because the implicit noun "science" is singular.
I wish we had something like Hetzner dedicated near us-east-1.
They do offer VPS in the US and the value is great. I was seriously looking at moving our academic lab over from AWS but server availability was bad enough to scare me off. They didn't have the instances we needed reliably. Really hoping that calms down.
This is potentially very interesting to me, but I'm having a hard time under exactly what it is. Could you give a little background on what motivated it, and what the core features are?
The motivation came from building desktop applications and working with awesome but cumbersome GUI toolkits like Nuklear.
I built a graphics backend-agnostic GUI library in CRuby called Hokusai, but Hokusai uses FFI, isn't portable, and is hard to distribute. (Need a Ruby interpreter on the target)
I ported the library to MRuby, developed some build tools, and now have a portable binary for different platforms that can run a dynamic desktop application/game that is written in Ruby.
If you notice the paint repository, there is nothing to build, just ruby scripts and assets.
The tool also has commands to build your application for different platforms as standalone binary, but I'm currently working in that space for other reasons.
There are of course constraints to using MRuby vs CRuby, but I hope I speak to how this library addresses those.
Yeah! That's pretty accurate, although it's not quite css/html.
It also integrates some helpful libraries, like libuv for cpu intensive tasks and I'm currently working on adding networking/HTTP and builds for android (it already runs on a pinephone).
The thing I think that is cool is that you don't need to compile your apps, you can just run them with the binary.
Tangent, but Slint is a really cool project. Not being able to dynamically insert widgets from code was the only thing that turned me off of it for my use case.
Agreed, I find Slint really interesting. To me, the biggest pain point is the very limited theming support. It's virtually impossible to make a custom theme without re-implementing most widget logic, which is a shame.
> As you can see from the version number, this release is not a 1.0 release. In fact, we still haven’t finished discussing what 1.0 means for Servo
Wait, crate versions go up to 1.0?
EDIT: Sorry, while crate stability may be an interesting conversation, this isn't the place for it. But I can't delete this comment. Please downvote it. Mods feel free to delete or demote it.
The fundamental problem with Rust versioning is that 0.3.5 is compatible with 0.3.6, but not 0.4.0 or 1.0.0; when major version is 0, the minor takes the role of major and patch takes the role of minor. So packages iterate through 0.x versions, and eventually, they reach a version that's "stable".
If version 0.7 turned out to hit the right API and not require backward incompatible changes, releasing a version 1.0 would be as disruptive as a major version change to your users and communicate through version semantics that it is a breaking change.
Semver declares that version 0.x is for initial development where there is no stability guarantee at all. This is the right semantics for a versioning system, but Cargo doesn't follow this part of semver. Providing stability guarantees throughout the 0.x cycle inevitably results in projects getting stuck in 0.x.
This is one of my biggest gripes with Cargo. But Rust people seem to universally consider it a non-issue so I don't think it'll ever be fixed.
> The fundamental problem with Rust versioning is that 0.3.5 is compatible with 0.3.6, but not 0.4.0 or 1.0.0
That’s a feature of semver, not a bug :)
Long answer: You are right to notice that minor versions within a major release can introduce new APIs and changes but generally, should not break existing APIs until the next major release.
However, this rule only applies to libraries after they reach 1.0.0. Before 1.0.0, one shouldn’t expect any APIs to be frozen really.
To go further, semver provides semantics and an ordering but it says nothing about version requirement syntax. The caret operator to describe a range of versions is not part of the spec. It was introduced by initial semver-aware package managers such as npm or gem. Cargo decided to default to the caret operator, but it's still the caret operator.
In practice, there's no real issue with using the first non-zero component to define the group of API-compatible releases and most package managers agree on the semantics.
Eventually this will get cleared up. I’m close than I’ve ever been to actually handling this, but it’s been 9 years already, so what’s another few months…
> If version 0.7 turned out to hit the right API and not require backward incompatible changes, releasing a version 1.0 would be as disruptive as a major version change
TL;DR: You take the 0.7 library, release it as 1.0, then make a 0.7.1 release that does nothing other than depend on 1.0 and re-export all its items. Tada, a compatible 1.0 release that 0.7 users will get automatically when they upgrade.
Even more interesting is that you can use this to coordinate only partially-breaking changes, e.g. if you have 100 APIs in your library but only make a breaking change to one, you can re-export the 99 unbroken APIs and only end up making breaking changes in practice for users who actually use the one API with breaking changes.
The standard library has a whole bunch of tools to let them test and evolve APIs with a required-opt in, but every single ecosystem package has to get it right first try because Cargo will silently forcibly update packages and those evolution tools aren't available to third party packages.
Personally, I think the 0 major version is a bad idea. I hear the desire to not want to have to make guarantees about stability in the early stages of development and you don't want people depending on it. But hiding that behind "v0.x" doesn't change the fact that you are releasing versions and people are depending on it.
If you didn't want people to depend on your package (hence the word "dependency") then why release it? If your public interface changes, bump that major version number. What are you afraid of? People taking your project seriously?
0.x is not that you don't want people depending on it, you just don't want them to come and complain when you quickly introduce some breaking changes. The project is still in development, it might be stable enough for use in "real projects(tm)", but it might also still significantly change. It is up to the user to decide whether they are OK with this.
1.x communicates (to me at least) you are pretty happy with the current state of the package and don't see any considerable breaking changes in the future. When 2.x comes around, this is often after 1.x has been in use for a long time and people have raised some pain points that can only be addressed by breaking the API.
If you are at the point that other people can use your software, then you should use v1. If you are not ready for v1, then you shouldn't be releasing to other people.
Because this comment, "The project is still in development, it might be stable enough for use in "real projects(tm)", but it might also still significantly change." That describes every project. Every project is always in development. Every project is stable until it isn't. And when it isn't, you bump the major number.
I think we can come up with a reason why bumping the version number each breaking change isn't an elegant solution either: You would end up with version numbers in the hundreds or thousands.
Indeed! I think both 0-based versioning, and this (maybe?) downside I bring up addresses the tension between wanting to limit the damage caused by breaking changes with retaining the ability to make them.
Versioning is communication. I find it useful to communicate, through using version 0.x, "this is not a production ready library and it may change at any time, I provide no stability guarantees". Why might I release it in that state? Because it might still be useful to people, and people who find it useful may become contributors.
Any project may change at any time. That's why they bump from v1 to v2. But by not using the full precision of the version number, you're not able to communicate as clearly about releases. A minor release may not be 100% compatible with the previous version, but people still expect some degree of similarity such that migrating is not a difficult task. But going from v0.n to v0.(n+1) uses that field to communicate "hell, anything could happen, YOLO."
By releasing a library with version 1.0, I communicate: "I consider this project to be in a state where it is reasonable to depend on it".
By releasing a library with version 0.x, I communicate: "I consider this project to be under initial development and would advice people not to depend on in unless you want to participate in its initial development".
I don't understand why people find this difficult or controversial.
For example, sometimes projects that have a 0.y version get depended on a lot, and so moving to 1.0.0 can be super painful. This is the case with the libc crate in Rust, which the 0.1.0 -> 0.2.0 transition was super painful for the ecosystem. Even though it should be a 1.0.0 crate, it is not, because the pain of causing an ecosystem split isn't considered to be worth the version number change.
99% of the time this situation is okay, because Cargo allows you to have both 0.1 and 0.2 in the same project as dependencies. It's just packages that call out to external dependencies, like libc, where it enforces the single version rule.
Most of the time, it works so well people don't even notice.
The only time you run into a problem is if you try and use values with a type from 0.1 with a function that takes a 0.2 as an argument, or whatever. Then you get a type error.
It's pretty amazing email hasn't been replaced, or at least joined, by an open protocol where you can't message someone without first being approved by them, either directly like Facebook messenger or through some sort of referral system.
We had a similar problem in the university. At the beginning of the semester, the students have to register for a Moodle server with additional material. So when they create an account, we have to send a few thousands of confirmation emails in a short period out of the blue, that makes Gmail/Yahoo/Outlook/Whatever unhappy.
The solution was to ask the students to send an email to the server half an hour before registering. It's not ideal, but it adds us to a secret list of known contacts of the student, so (most) emails are delivered.
> we have to send a few thousands of confirmation emails
What are you confirming, and why do you have to send it as E-mail? If it's sign-ups, just "confirm" using the same system that the user used to sign-up. Presumably HTTP.
on most services you sign up by using an email address (or a phone number) as an identifier. these need to be verified to make sure it's actually yours and not someone else's, or a typo.
If you used a username, you wouldn't have this problem. As it stands, signing up someone else's address for a lot of sites to spam them with confirmations is already an attack vector that's used in the wild. And that's legitimate spam and should be reported as spam and sites that do this are spam amplifiers.
They don't need to be verified through E-mail or through the phone, though. A simple landing page after you sign up that says: "We signed up [E-mail] for this service using [phone number]. If this is incorrect, [click here] to make corrections" would work, too.
Frankly, I'm getting tired of having to constantly "verify" this and "confirm" that every time I sign up for or log into an online service. It's especially annoying after I've already signed up. Every bank that I haven't logged into for the last 5 milliseconds hits me with a "confirm your E-mail yet again" flow. I'm going to just start using "password" for my password if these guys keep insisting on round-tripping through my E-mail every time I need to do anything.
We didn't want too many fake accounts. We didn't ask for phone numbers. It's very easy to get a burner email, in case someone wanted to avoid giving the main email. Burner phone numbers are harder.
Also, an important use is password and username recovery. We even got password or username request 30 minutes after signup! They had quiz to solve if they want to help during studding and it's good to track them.
We had a lot of wrong emails, in particular it was common someone@yahoo.com instead of someone@yahoo.com.ar because Yahoo! offer both options. Also someone@gmail.com.ar that does not exist, but that never stop users.
(If it help, we never asked to confirm the email again after the registration.)
how do you prevent malicious use intentionally signing up someone else without verification? and how do you verify your own email if you are not technically competent enough to know how to spell your email correctly? (probably not an issue for students, but just seeing stories here on hackernews about people receiving emails not meant for them shows that this is an issue)
I guess whether that matters depends on the actual application. As long as it's not spamming (E-mail or phone), the impact of having an incorrect email address may be low.
IIRC, we don't give an automatic email for students.
I'm in the first year of the University of Buenos Aires. Everyone with a high school title can get into the First Year, no filtration before the first year. There are more than 50.000 students per year. The fist years is shared between the 13 Faculty (branches?). Each one has a different policy about the email for students. Moreover, inside each faculty each department has a different policy about the email for students (IIRC ~20 years ago in computer science every student got an email, but in math you got an email only after getting a undergraduate-TA position in ~3rd year).
Now the whole University has a deal with Microsoft so I got an email there. And also the First Year has a deal with Google so I got another email. Each faculty may self host or has another(s) deals with someone else, so I have another email in my old faculty. Three in total. I may even ask nicely to get a email as visitor in other departments/faculties, but I'm too lazy to do that. And some coworkers work in two or more faculties so add a few more emails for them.
Back to students, I have no idea how many emails they get now. Also, they may get the email a few months after the semester began, or not, I'm not sure and in the best case we definitively can wait until all the paperwork is done.
which system does that? neither telegram, nor whatsapp do it, and it annoys the hell out of me. at least whatsapp tells me that the sender doesn't get a notification until i respond or add the contact. wechat actually requires a connection request before allowing you to message someone, with all the complaints about privacy, wechat has the better UX to avoid getting spammed, linkedin requires a connection too, if you don't have a pro account. i don't know about any others.
Well you can already do this with email, can't you? You just use [company-name]@[yourdomain].com. Or you+[company]@gmail.com. Then you either block all unknown, or more practically just block companies as soon as they start spamming you.
I saw the one in Houston for the first time last week. It was so cool. My favorite spacecraft as a kid, but in real life it was about 4x as big as I expected.
I'm fine with 16 but they should have only used the bytes as they were needed, at least for 5 and 6 byte addresses, so those who desire short addresses could buy them.
My vrrp address for my dns server at home is 2001:8b0:abcd::53
It's about as easy to remember as 81.187.123.45//192.168.0.53
Almost all ipv6 addresses I encounter start with 2001, so I just need to remember my home prefix is 8b0:abcd, which is about the same length as my home public IP of 81.187.123.45
::53 means subnet zero host 53, which is easier to remember than which rfc1918 range I used (and basically is the equivalent of remembering the 2001:: prefix)
If I have an internal server I'd have on 192.168.4.12 I could address it with 2001:8b0:abcd:4::12 just as easily, with the "4.12" translating to "4::12", and the "81.187.123.45>192.168.x.y" translating to "2001:8b0:abcd:x::y"
Just because slacc gives you an extra 64 bits of randomness doesn't mean you need to use them.
fe80:: is for link local. You'd want to use something starting fc00:: or fd00::
In your typical home environment, just set your ULA to fd00::12 instead of 192.168.0.12, or fd00:16:34 instead of 192.168.16.34
Yes you'll run into issues if you were to later want to merge your private IPs with someone else, and you should use fd12:3456:7890::12 instead, remembering those extra 10 digits, but its not a problem at home, and no more of a problem with business mergers than ipv4 clashes anyway.
Wait is British "maths" a singular noun or is this a typo? I was willing to go along with it if it was plural, but I have to draw the line here.
reply