Its frustrating because these issues are all fixable, and some of them are just bugs, but there's a mentality in this kind of science communication that ehh it doesn't matter because its just for the public. This does a real disservice to what people are trying to actually achieve in educating the public. Its also, unsurprisingly, a lot of hard work and validation to get from visualisation-grade, to physically accurate, and its a lot easier to not do that
The only criticism is to call that accurate, when it's simplified. OP ist defending the use of accurate with dumb arguments. The fix would simply be to not claim "accurate" and continue to provide a probably great visualisation (idk, haven't looked at it)
Note that most of the points you raised are clearly not bugs – most notably, things like non-rotating black hole or colormap choice. At the very most, these can be considered missing features, but they don't affect correctness in any way.
You seem more interested in putting effort downplaying criticism and upholding the optics of "scientifically accurate thing from researcher in big name university" than actually putting effort on making the thing even better by using the amazing feedback you got...
Now after reading the OPs responses and how defensive they are of some high quality constructive criticism, I don’t even want to go back and play more with the visualization.
that's wrong in the sense it won't be useful for anything unless you have a dozen of those small things setup in the very specific way the author envisioned you set them up.
you seem to be repeating all the marketing, while mentioning in other comments you never understood any init system. i don't think you're the authority to be adding so many comments here.
You can forward logs to rsyslog or something, but you really can't disable systemd-journald. Technically you don't need to run systemd-boot, you can use grub or something else, but then bootctl and systemd kexec stop working. You don't need to run dbus, but if you don't several systemd features break, and it's not even documented what needs it. The list goes on and on.
Also, the fact that all components are in the same repository and need to be built together causes a lot of headaches with packaging due to dependency cycles (like, systemd -> cryptsetup -> lvm2 -> udev -> systemd).
Systemd is literally not a monolith because it's not one big piece of software. It's a collection of software. For example, systemd-boot has basically nothing to do with systemd-init.
Yes, some software is more tightly coupled than others, naturally. systemd-init and systemd-journald work tightly together because logging is a core requirement of any init system.
Just the PID 1 manager is multiple times larger in LoC than any alternative. There is no metric in which systemd is more lightweight that I could find.
I'm not sure this is true in practice, if we're counting init scripts themselves. Which we should, because init scripts are code and they often re-implement standard systemd features. Usually in wonky, broken ways.
What about other init systems? The GP said "any alternative." I am not familiar with how complex they are but was under the impression that there are a number much simpler than sysv init?
I think that even if we count init scripts which are way different level of complexity than C LoC, the Systemd would still be larger. Especially if we count just the scripts that are deployed.
No way. I was easily able to create Systemd units from 0-knowledge, where the init system remains a big black box riddled with question marks for a very long time. Very little was documented.
There may be many reason other than rejecting that suggestion leading to what it is know. Your statement somehow suggests that it was deliberately decided against what you propose. I don't think we know that.
I can't quite picture how operator overloading would look like, could you give an example?
> I can't quite picture how operator overloading would look like, could you give an example?
Instead of this:
self.filter(end__gt=self._midnight(today))
You could write a "Field" class that implements __getattr__ and __gt__ so you could do
self.filter(Field.end > self._midnight(today))
The "Field.end > self._midnight(today)" would evaluate to an object that would just store "my field name is end and my value needs to be larger than xyz".
filter() can then look into its argument list and construct the filter criteria from the passed Field objects instead of the key value pairs as it does now.
SQLalchemy does that. One advantage of the Django syntax is that it can be (pretty much) directly dropped into a query string on any admin page or DRF query and filter the results. E.g. the admin page for all the events after noon today:
admin/event/?end__gt=2026-07-26T12:00:00
Being able to do ad-hoc queries using the same paradigm your app queries are written in, and then pass urls around with those queries included (e.g., quick one-off reports or answers to client questions) is so helpful.
Not if you do the magic with getattr and comparison overrides.
You actually need to do it on the metaclass because the Field as I wrote it isn't an instance but this works:
from datetime import datetime
class Filter():
def __init__(self, name):
self.name = name
def __gt__(self, value):
return {
"field": self.name,
"operator": ">",
"value": value
}
class FieldMeta(type):
def __getattr__(cls, name):
return Filter(name)
class Field(metaclass=FieldMeta):
pass
print(Field.end > datetime(2024, 1, 1))
You can make python return arbitrary values for comparisons by overriding __gt__ (and lt, eq) on the first operand (which we control here since it is a Field class), it doesn't have to be a bool.
Edit:
You can even make a little adapter to use this with the current filter system if you really want to:
from datetime import datetime
class Filter():
def __init__(self, name):
self.name = name
def __gt__(self, value):
return {
"field": self.name,
"operator": "gt",
"value": value
}
def __lt__(self, value):
return {
"field": self.name,
"operator": "lt",
"value": value
}
def __eq__(self, value):
return {
"field": self.name,
"operator": "eq",
"value": value
}
class FieldMeta(type):
def __getattr__(cls, name):
return Filter(name)
class Field(metaclass=FieldMeta):
pass
def _(*args):
kwargs = {}
for arg in args:
k = arg["field"] + "__" + arg["operator"]
kwargs[k] = arg["value"]
return kwargs
def filter(**kwargs):
for k, v in kwargs.items():
print(f"{k} = {v}")
filter(**_(Field.end > datetime(2024, 1, 1)))
That's a well established pattern in Python, for instance with Numpy. That's the point. Operations in Python aren't "mean to return" anything in particular. Each class can define the operations as it wants. That's a powerful feature that allows creation of specialized expression languages, as used by other ORMs besides Django.
No it won't, because there's no requirement that the result of `>` be True or False. It can return an object that then can participate in further expressions that "keep track" of what operations are done to the fields.
Yeah, but that's different from the operator. It's a different way of thinking about it. Maybe that's the reason they used dou le underscores for everything, to keep it consistent.
Not really. Both method calls and operators are consistent with how Python normally works. Outside of Django you never do `obj__op(value)` or `obj__meth(value)` to do the equivalent of `obj op value` or `obj.meth(value)`. It is Django that is inconsistent with how operations are done in Python.
It's not worthless, you don't have to agree with P on everything, or make it personal - it works as strictly business - only where and when appropriate.
Ah yes, chosing a name that transports openness and transparency when the opposite is the case, and complaining about not being able to register that name as a trademark, which will cause financial harm the said company -- but somehow there's still people to spin it the other way around so it harms consumers now, therefore it was a bad decision.
You just don't like OpenAI and are for anything that hurts them, without thinking through the consequences.
What will harm consumers is the scammy "OpenAI" chat app that I can now legally upload to app stores in the EU, in hopes of tricking people into thinking it's a genuine app.
It seems pretty dubious that there are a lot of people who know the name of the company behind ChatGPT but not able to recognize that the name of their chat isn't "OpenAI chat"
I reported 3 errors/feature requests in Oura Ring app. After going through the reporting process I felt much less irritated at the bugs and smiled to myself thinking that must have been the purpose of the reports.
To my astonishment, 3-4 months later they fixed the errors and rolled out the feature I asked about.
WTH, people read those reports?
I know people do, I often get in touch with support for various services, knowing that in the sea of people not giving feedback, your comments mean a lot. But up until recently both the Oura App and their support was very mediocre.
I guess Oura hasn't heard the feedback about outsourcing their support/engineers yet! Enjoy knowing you made their app better, I'm sure with time it won't work anymore, sadly
It is bad because some commands that are in coreutils are conflicting with cmd commands or Windows binaries?
The only thing bad is that take. It's an optional package. It doesn't overwrite any cmd commands or Windows binaries be default. So the user can decide what to install and what to use. It gives full flexibility.
If you say that's a bad choice, I think you're more commenting on your inability to work with these tools, than the tools itself.
It has conflicts all over the place, and requires being skilled across UNIX, Powershell and cmd, to fine tune the PATH and Windows Terminal sessions in order to get the right executables, depending on what one is doing.
As for my skills, I have been coding since 1986, and even though Windows is my main platform, I have used more UNIX flavours in all those years than most HN commmenters.
reply