-
Imho this sounds like what is potentially/usually addressed by the AGPL.
-
-
-
It doesn’t address the core problem. Most OSS companies have a business model that revolves around support. If a large hosting provider like Amazon comes in and provides an “as a service” version, that cuts off a primary revenue stream. If said hosting provider doesn’t produce improvements to the codebase then AGPL doesn’t matter.
-
-
AGPL says you have to release improvements. It doesn’t make you contribute to the community.
If a community is getting a lot of financial support from a company like Redis Labs paying for core open source work, a company like Amazon can come along and do an as a service version and contribute nothing. AGPL does nothing for that.
The issue is many projects are pushed forward by commercial offerings that rely on support/services as a means to provide financial support. Our open source licenses provide no protection for that model.
Perhaps the model is flawed and we need something better. But there is no protection from parasitic behavior in that case.
It extends further though, in general, there’s no way for an open source community to develop a means to financially support itself and not rely on free labor that is free of concerns. But that’s another topic.
The world has changed around free and open source. They haven’t adjusted to that change beyond AGPL being created to address some issues.
I personally don’t think that commons clause is the right solution but I understand the problem they are looking to solve.
Apologies for any typos. I answered this from my phone.
-
-
-
-
Companies dual-license under both GPL and AGPL. So, it could be done AGPL with cloud vendors paying a license. There’s a lot of FOSS developers that oppose the AGPL, though.
-
-
-
AGPL
The previous license for the 3 modules in question was previously AGPL.
-
It absolutely is. Read the FAQ section on the AGPL, it’s very unclear. ‘Many features of the AGPL…’ kind of language. What features? It’s not the Linux kernel, it’s a license, it’s pretty small, just say what these supposed features are.
Of course the reason they don’t is that it’s a smokescreen: the AGPL is of course fine, but their goal isn’t to make the software free, it’s to profiteer off it.
-
Yes, Redis Labs is in the business of paying people to work on Redis and the Redis ecosystem and needs to make money to do that. The business model for companies such as that is based on support. If someone cuts off that revenue stream the money falls apart. We can as a community accept that such companies will need to build protections for themselves (licenses like common cause or having some closed source components) or accept a world in which there are no companies that exist to support specific products that could be turned into as “as a service” by a large player.
The AGPL does nothing to stop someone like AWS from taking what Redis Labs does and making money off of it and wrecking the Redis Labs business model (which is shared by a number of companies). I commend them for trying an approach that leaves the module source available and even “open” for some segment of the user base. The alternatives are “new business model”, “go out of business”, or starting to make more and more of their offerings closed source.
-
The AGPL does nothing to stop someone like AWS from taking what Redis Labs does and making money off of it and wrecking the Redis Labs business model (which is shared by a number of companies).
Nonsense. AWS wouldn’t touch an AGPL redis with a ten foot barge pole.
AGPL/commercial dual licensing is actually open source.
I commend them for trying an approach that leaves the module source available and even “open” for some segment of the user base. The alternatives are “new business model”, “go out of business”, or starting to make more and more of their offerings closed source.
Calling this open is literally telling a lie.
-
-
-
-
This is quite awesome. I have to start planning my Steambox again.
If somebody makes a decent Steambox (AtariVCS is promising, but the hardware is probably too weak), Sony and Microsoft are gonna be in trouble. Not right away, but this will definitely slowly chip away chunks of their markets. Who wants a console whose software goes totally obsolete in 5 years, when you can have Steam? The first game I ever had on Steam, Half-Life, is still playable on my modern Linux!
-
This site was readable with all javascript blocked. That’s nice! I’m actually considering this instead of the Cobalt-based blog generator that I’m building on now.
But I think I’m gonna keep Cobalt still, to have better control of the lowest levels. Even if it means that many details will be worse.
-
My almost-ready-to-be-published blog will be ad-free and tracking-free, and generally javascript-free. But I’m not gonna fool myself by thinking that anyone cares.
-
As someone who never used Rust I want to ask: does the section about crates imply that all third-party libraries are recompiled every time you rebuild the project?
-
Good question! They are not; dependencies are only built on the first compilation, and they are cached in subsequent compilations unless you explicitly
cleanthe cache.-
-
A Rust library includes the actual compiled functions like you’d expect, but it also contains a serialized copy of the compiler’s metadata about that library, giving function prototypes and data structure layouts and generics and so forth. That way, Rust can provide all the benefits of precompiled headers without the hassle of having to write things twice.
Of course, the downside is that Rust’s ABI effectively depends on accidental details of the compiler’s internal data structures and serialization system, which is why Rust is not getting a stable ABI any time soon.
-
-
-
-
I should’ve been more clear. Rust will not recompile third-party crates most of the time. It will if you run
cargo clean, if you change compile options (e.g., activate or deactivate LTO), or if you upgrade the compiler, but during regular development, it won’t happen too much. However, there is a build forcargo check, and a build forcargo test, and yet another build forcargo build, so you might end up still compiling your project three times.I mentioned keeping crates under control, because it takes our C.I. system at work ~20 minutes to build one of my projects. About 5 minutes is spent building the project a first time to run the unit tests, then another 10 minutes to compile the release build; the other 5 minutes is spent fetching, building, and uploading a Docker image for the application. The C.I. always starts from a clean slate, so I always pay the compilation price, and it slows me down if I test a container in a staging environment, realize there’s a bug, fix the bug, and repeat.
One way to make sure that your build doesn’t take longer than is needed to is be selective in your choice of third party crates (I have found that the quality of crates varies a lot) and making sure that a crate pays for itself. serde and rayon are two great libraries that I’m happy to include in my project; on the other hand, env_logger brings a few transitive libraries for coloring the log it generates. However, neither
journalctlnordocker container logsshow colors, so I am paying a cost without getting any benefit. -
-
Definitely, this is why MLton is doing it, it’s a whole program optimizing compiler. The compilation speed tradeoff is so severe that its users usually resort to using another SML implementation for actual development and debugging and only use MLton for release builds. If we can figure out how to make whole program optimization detect which already compiled bits can be reused between builds, that may make the idea more viable.
-
In last discussion, I argued for multi-staged process that improved developer productivity, esp keeping mind flowing. The final result is as optimized as possible. No wait times, though. You always have something to use.
-
-
Interesting you mentioned that; Chris Cannam has a build setup for this workflow: https://bitbucket.org/cannam/sml-buildscripts/
-
-
-
-
-
-
-
Someone who writes ostensibly production-ready code in PHP or Perl should be treated like someone who refuses to vaccinate their children: their behavior should be considered acceptable only if they are extremely careful and they have a very good excuse.
I think the author is a bit melodramatic, and that is the toxic part – there’s criticism, and then there’s criticism without concern for the humans receiving the criticism. I agree with the author that there’s a vast majority of programmers who could benefit from better tooling (I put myself in this camp), but how that knowledge is conveyed makes all the difference (as they mention in the article itself).
It sounds like the author has knowledge and wants to spread it – either by mentoring or teaching directly. To be successful at that, they need to understand where a mentee/student is and jump into their worldview before moving them forward. There is a huge difference between “here is where I think you are, which means you’ve probably seen these kind of frustrations pop up, why not try X instead” and “hey you’re doing this all wrong, here’s the best way.”
Sidney Dekker talks about how people don’t show up at work to do a bad job – everyone is usually trying their best, but is working within constraints (“my boss won’t let me use X”, “I haven’t heard about this,” “I have outdated knowledge about this,” “I don’t want to support this organization for moral reasons,” “I’m under a tight deadline and can’t afford the rewrite,” etc). People will only be receptive if you acknowledge that they are doing their best within constraints, and you are removing a constraint. “You use PHP, therefore you are bad” statements make you feel good and self-righteous, but are less effective than “do you hit these kinds of errors?” “yes!” “then you might consider this other language, it’s easier than you think.”
As I write this I feel a bit hypocritical as I’ve spent a long time criticising {large, well known software product with a defensive, tribal culture} for not doing {well established modern software engineering practice} and releasing a buggy and infuriating product. My ranting and raving did nothing. Absolutely nothing. What was effective? Another team got merged into that one and started flooding the mailing lists with “you thought {software engineering practice} was impossible at this scale but it’s actually doable.” It worked. That’s how you effect change in organizations that might even be hostile to you: meet them where they are, treat them as doing their best within constraints, and show how to remove the constraints.
-
I think the author is a bit melodramatic, and that is the toxic part – there’s criticism, and then there’s criticism without concern for the humans receiving the criticism.
Absolutely. I fell into that trap recently. The organisation I was in was using PHP, and I engaged what I thought at the time as collegial bitching at that poor language. Turns out they were mostly humoring me and taking a minor bit of offense at each nag, and the taken offense piled up in time.
It was a lesson for me obviously, but there’s something to be learned on the other side of this fence: if you’re getting offended by something your colleagues do, bring it up very early and don’t just assume the offender is aware of how they’re affecting you.
-
I actually make this point later in the essay:
I consider this really to be an issue of beginners graduating to higher levels of understanding (and systematic pressure making it harder for certain groups to graduate out of the beginner classification), and one way to help this is to be extremely clear in your criticisms about the nature of the problems you criticize — in other words, rather than saying “PHP users are dumb”, say “PHP is a deeply flawed language, and PHP users should be extremely careful when using these particular patterns”.
When we are talking to individuals, I think we have the responsibility, as @stip says, to “understand where a mentee/student is and jump into their worldview before moving them forward”. However, one-on-one mentoring is not where programmers of any level learn most of their habits these days (and I’m not sure it ever was!). Instead, the most powerful shapers of industry and community norms are publications (ranging from comments and blog posts to books and standardized lesson plans) and myth (ranging from hype and stereotypes to stuff like programming epigrams and The Story of Mel). Publications shape myth through hyperbole, so if you’re writing for a very general audience, it pays to be melodramatic enough to be memorable.
(While overwrought, I don’t think the comparison to antivaxxers is unfair. Using insecure tools in serious projects because you think it doesn’t matter bites you in the ass when the project suddenly acquires scale and problems start affecting every install, in the same way that an individual decision to avoid vaccination becomes a failure of herd immunity at scale. The fundamental mistake is the same: evaluating decisions about interactions with a group from only an individual lens.)
Something I originally meant to address more directly in this piece is a flaw I see in articles of the type it criticises – namely, I think social pressure is extremely valuable because it performs soft enforcement of rules, and articles critical of gatekeeping in tech often ignore the social dynamics of this. The particular article I’m responding to only bumps up against the problem.
Ultimately: when your software doesn’t matter (when it has zero or one users, or all its users are also its core developers, and when nobody ever pays for it, uses it for important tasks, or gives it sensitive data), then tool choice also doesn’t matter. This is great! But, when your software matters (when people depend on it working), making sure it’s reliable and secure matters more than your ego and personal preferences. At this point, so long as they properly modify behavior in the appropriate direction, social pressure (to the point of hostility) is justified.
When I see people complain that they get criticized for using in a serious project & their defense is that they’re a beginner and don’t know how to use something better-suited for the job, my basic response is that when somebody is depending on a project, it shouldn’t be implemented by someone who doesn’t know how to implement it reliably. (Making sure the thing works is more important than even profit: if you can only do a half-assed job without going broke, you shouldn’t do it at all.) In the extreme case, you work on it until it is reliable (by learning new techniques and tools) and discourage people from depending on it (by marking it alpha) until it’s actually release quality.
(And, of course, on the other side: when nobody depends on it, we should encourage beginners to expand their horizons by using all sorts of tools – particularly tools that are a poor fit – since dealing with a poorly-fitting tool when both the tool and the problem are new to you is a very productive learning experience.)
-
-
-
Everytime I see a post for Nim I am hoping for a Golang competitor that can actually bring something new to the table. But then I look at the library support and community and walk back disappointed. I am still hoping for nim to take off and attract Python enthusiasts like me to a really fast compiled language.
-
But then I look at the library support and community and walk back disappointed.
It’s very hard to get the same momentum that Go achieved, just by the sheer fact that it is supported and marketed by Google. All I can say is: please consider helping Nim grow its community and library support, if everyone sees a language like Nim and gives up because the community is small then all new mainstream languages will be owned by large corporations like Google and Apple. Do you really want to live in a world like that? :)
-
How about https://crystal-lang.org
-
Have tried it; GC is way to optimistic so under high loads you would see memory being wasted. I love the syntax and power of language but it still stands shy when you can’t compile single binary (like golang) and end up with weird cross compile issues. Nim is way more efficient in terms of memory and GC overhead.
-
-
-
I think that’s more a result of Go having the manpower to develop and maintain an SSL library written in Go. As far as I understand, if you were to write an SSL library in 100% Crystal you wouldn’t have this problem.
By the way, Nim goes a step further. Because it compiles to C you can actually statically embed C libraries in your binary. Neither Go nor Crystal can do this as far as I know and it’s an awesome feature.
-
Is there a distinction between “statically embed C libraries in your binary” and “statically link with C libraries”? Go absolutely can statically link with C libraries. IIRC, Go will still want to link with libc on Linux if you’re using cgo, but it’s possible to coerce Go into producing a full static executable—while statically linking with C code—using something like
go install -ldflags "-linkmode external -extldflags -static".-
There is a difference. Statically linking with C libraries requires a specially built version of that library: usually in the form of a
.aor.libfile.In my experience, there are many libraries out there which are incredibly difficult to statically link with, this is especially the case on Windows. In most cases it’s difficult to find a version of the library that is statically linkable.
What I mean by “statically embed C libraries in your binary” is: you simply compile your program’s C sources together with the C sources of all the libraries you depend on.
As far as Go is concerned, I was under the impression that when you’re creating a wrapper for a C library in Go, you are effectively dynamically linking with that library. It seems to me that what you propose as a workaround for this is pretty much how you would statically compile a C program, i.e. just a case of specifying the right flags and making sure all the static libs are installed and configured properly.
-
-
-
-
You have to jump through quite a few hoops to get dynamic linking in go.
By default it statically links everything, doesn’t have a libc, etc.
-
-
It’s not uncommon or difficult in go to compile a webapp binary that bakes all assets (templates, images, etc) into the binary along with a webserver, HTTPS implementation (including provisioning its own certs via ACME / letsencrypt), etc.
-
-
There are different approaches, https://github.com/GeertJohan/go.rice for example supports 3 of them (see “tool usage”)
-
-
-
-
I think he mentions the ability to statically build [1] binaries in Golang. I’d note that this is a feature that is not so common and hard to achieve. You can do this with C/C++ (maybe Rust), but it has some limits, and it’s hard to achieve with big libraries. Not having statically built binaries often means that you need a strong sense of what you need and to what point or using good packaging/distribution workflows (fpm/docker/…).
It’s a super nice feature when distributing software (for example tooling) to the public, so it feels like “here you are your binary, you just have to use it”.
-
-
-
-
The “programming by duct taping 30 pip packages together” method of development is pretty new, and it isn’t the only way to program. Instead, you grow the dependencies you need as you build your app, and contribute them back once they’re mature enough.
More time consuming, but you have total control.
-
-
Don’t use N computers when 1 will do.
This is so important, because people seem to forget that computers are fast. Really fast. Absolutely, mind-mindbogglingly fast. CPUs operate on a level of granularity of billionths of a second, while humans can barely sense thousandths of a second.
The only reason computers are “slow” is because most software is crap. I mostly blame Windows and the Web, since they’ve mislead average computer users into believing they have to wait for bloat to run (rather than regularly shouting at developers to profile their code).
An average laptop running F-Stack and a decent web server could host a website and handle millions of concurrent requests per second. Distributed systems on AWS are nice and all, but they’re way harder to build than systems that run on a single server. And they’re far harder to profile and optimize.
/rant
Out of curiosity, I wonder how the author managed to handle concurrency in SQLite, since it locks the whole DB on writes. He mentions writing multiple SQLite databases, but I’d be interested in more details.
-
Hmm, not come across F-Stack before. Ironic, in the context of your rant, that opening their page showed me nothing but a loading animation for a few seconds :P
-
Out of curiosity, I wonder how the author managed to handle concurrency in SQLite, since it locks the whole DB on writes. He mentions writing multiple SQLite databases, but I’d be interested in more details.
He also mentions using a nifty new (first appeared in 2010 :)) SQLite feature called WAL (Write-Ahead Logging). It makes writers and readers not block each other, plus it makes writes so fast (essentially just an append to a log) that they very rarely block each other.
I’m not sure why it’s not on by default, but that’s probably just standard SQLite conservatism in practice.
-
-
Despite not having any need for Rust (just as I have no need for C++ in the things I work on - performance at that level just doesn’t matter for my projects), I am continually surprised at just how great Rust is as a language and as a community. It just seems to be filled with helpful friendly people. It’s certainly not the only community that’s friendly, I’ve found Python and Lisp to both be pretty friendly communities too, but reading stuff like:
There’s been quite a bit of noise recently about the amount of unsafe code in the actix-web framework. I won’t discuss the merits of grabbing the pitchforks as soon as someone writes code of a buggy and unidiomatic nature…
And then I click on the link and it’s a bunch of people calmly and rationally discussing some code. For the Rust community, that is grabbing the pitchforks: people saying that some code is concerning in its use of
unsafe.Compare to some communities (cough Javascript) where it’s not unusual to see pull requests and issues on GitHub and other platforms flooded with hundreds of comments absolutely dogpiling someone that wrote some silly code when they were a new programmer that, totally unbeknownst to them, was picked up and used by someone in a large company (with no oversight, clearly) and is now a dependency of a major library.
Also, cool article.
EDIT:
The code is a bit convoluted, because of the reason described in the comment. drop can panic 5, so the function must decrement the length before dropping an element. In case of a panic, the last element of the Vec will be a valid one.
I was under the impression a panic in Rust was unrecoverable. Does it matter if the data structure is left in an inconsistent state if
droppanics? I thought that not having to reason about exception safety was considered a selling point of not having exceptions.-
I was under the impression a panic in Rust was unrecoverable. Does it matter if the data structure is left in an inconsistent state if drop panics? I thought that not having to reason about exception safety was considered a selling point of not having exceptions.
Panics in Rust are unrecoverable within a task. You can catch them (for example, before unwinding into a piece of C-code, which is undefined) using
catch_panic. Still, there’s guarantees around panic, and that being that all owned values affected are properly _drop_ped and especially, memory safety is not violated in the process. Now, imagine the panicing code has the data structure borrowed and triggers the panic. The original value continues to exist and must be in a consistent state.Mutexes are a good example of a structure that has to deal with that problem. As Mutexes cannot reason about the operations on the data they contain, they become poisoned in such a situation.
Safe Rust allows you not having to reason about exception safety, unsafe on the other hand… is unsafe Rust ;).
Panics in drops are rare (and generally recommended against), but they may happen…
Another observation: in this case, they may lead to a memory leak, but leaking is safe in Rust. Dropping twice is illegal.
-
While you’re right about Rust community being friendly (even by force at times), the actix discussion wasn’t all happiness. The unsafety was first sort of ignored by the devs, which made some people claim that the developers of actix are completely untrustworthy, and shouldn’t be trusted in any future project either. That understandably made the actix devs a bit unhappy, probably on the verge of just dropping everything and walking away, but fortunately they decided to fix things instead.
So it was pretty good in the end, but the road there was a bit worse than you described, IMHO.
-
-
I’m so happy to read about the progress on this, we need this on linux though! Who is interested in developing this?
-
I’d assume that the answer you’d get if you ask a Linux kernel developer is “use SELinux or AppArmor”.
But if we’re wishing for arbitrary things, then I’d also like for strlcpy, strlcat and the arc4random family to be an actual part of POSIX and subsequently adopted by glibc/Linux.
-
Or Smack for those favoring simplicity. Looking at the link, I just found out it got big in automotive Linux, too.
-
-
The closest equivalent on Linux are probably the systemd filesystem sandboxing options: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ReadWritePaths=
-
-
Culture and priorities are different. Linux’s specifically targets what brings in mainstream and corporate audiences. OpenBSD explicitly rejects a lot of that to be simpler, more UNIX like, or quality/security. Lastly, there’s more attempts to sell Linux-based systems that generate revenue that can fund development.
-
-
-
Mex
1 month ago
|
link
| on:
Atlassian announces new partnership with Slack, will discontinue Hipchat and Stride
Does anyone have any experience with Microsoft Teams? We are looking at it as a potential replacement.
-
My team (roughly ~40 people) transitioned from Slack to Teams a bit over a year ago. It’s gone well and speaking in terms of productivity, it’s been an improvement. There are a lot of cool integration features with Teams but they’re more oriented to the Microsoft ecosystem whereas Slack was more open. We do everything w/ Microsoft here (Azure, VSTS, .NET, Office 365, etc)so it worked out well.
Slack has more ‘fun’ features like custom emojis - we had to give up all the funny faces of team members in the transition.
If your company isn’t in the Micorosft ecosystem I don’t think I would recommend it.
-
It’s reliable and has plenty of good features, especially on the management side, but the UX is not excellent. Some people even claim to hate it, but I haven’t figured out how serious those feelings are.
They have been improving it in a nice pace in 2018. It feels to me that the Teams team in Microsoft is culturally similar to the Visual Code Studio folks – i.e. part of the new Microsoft.
Like dsschnau says, you can probably find better solutions if you’re not in the Office365 bearhug already. But they won’t be massively better (unless you want the burden of hosting yourself, in which case there are plenty of choices). If you are paying for office365 (not to mention Azure/VSTS/TFS) already, getting another chat solution in addition to Teams would be just stupid.
-
-
-
-
I’m pretty much totally in support of this thesis. Simplicity is imperative.
Interesting cultural note: the Hacker News crowd pretty much disagreed (https://news.ycombinator.com/item?id=17489934). Most of the commenters there thought that correctness should be first.
-
-
I’ve become more and more disillusioned with NixOS over the past couple of months. Packaging things that aren’t available, or even updating existing packages, has so many little undocumented gotchas that (I guess) they assume you’ll figure out reading from reading gh issues or random blog posts. It has actually stopped me working on a few different projects because it’s not worth figuring out how to package something.
However, I don’t think I can go back to a traditional distro after tasting the stability and convenience of something like NixOS. Has anyone here tried both NixOS and GuixSD. or perhaps switched from one to the other?
Guix seems so much better documented from the brief read though I’ve given it after seeing this. The docs just have so much detail.
Also, I’d much rather learn a real language like scheme for making packages than the rather incomprehensible (at least to me) language that Nix invented.
What are the downsides of Guix that I just haven’t seen yet?
-
Guix has fewer packages, because they have a smaller community. Being a GNU project, they attempt to limit the amount of non-free, or license-incompatible, software as much as possible: using linux-libre, nearly no potential ZFS support, no Intel microcode, etc. If your hardware depends on a binary blob, you might have to jump through several hoops to get it working. As of 2018-07-06, they don’t have LVM support.
That said, guix seems far better thought out than nix. It does not rely on a particular init ecosystem (cough, systemd, cough). It has more features available without installing additional packages, for example:
guix importinstead of the myriad ofpypi2nix,nix-generate-from-cpan, etc packages that are separately written;guix environmentmakes creating an isolated container as easy as its normal environment isolation; etc. And guix is most certainly better documented.If you’re comfortable packaging software yourself (and don’t mind doing so), some of these problems could be fixable. You can keep (or contribute to) a non-free guix repository (such as these, but these do not seem to be well maintained, nor will the be approved of, probably). One could also use
guix importto import from a local copy of nixpkgs (though such an import is imperfect, and might require manual maintenance), or run guix atop NixOS.Unfortunately, I needed a system that works with nearly-minimal hassle on my hardware, with my software, and that is what NixOS gave me. The nix language is quaint, and the reliance on bash and systemd rather annoying, but personally I can ignore that and use a working computer with a relatively nice environment management system.
-
It does not rely on a particular init ecosystem You are referring to Guix, the package manager here, right? Because, as far as I understand, GuixSD, the Linux distribution does depend on https://www.gnu.org/software/shepherd/?
-
I was referring to the fact that neither Guix nor GuixSD rely on systemd. But you are correct, as best as I can tell GuixSD seems to rely on Shepherd.
Though maybe not all services seem to rely on it? Some of them don’t seem to mention shepherd at all, but I can’t tell whether or not that means anything because I’m not well versed in Guix scheme.
-
https://github.com/guix-mirror/guix/blob/master/gnu/services/ssh.scm
Here’s one example that clearly refers to shepherd. Is there any reason to believe that shepherd is better than systemd?
-
Three things, maybe:
- Shepherd doesn’t try to be more than an init system. Contrast to Logind, which GNOME depends on, which is tied to systemd. elogind had to be forked and extracted from systemd, because otherwise GNOME would not work without it. I don’t know of any end user applications that require shepherd to be the init system in any way that doesn’t resemble init system / daemon management usage.
- shepherd is also written in scheme, which means that Guix expressions can easily generate code per the user’s configuration for the shepherd file since you’re just going from scheme to scheme.
- I can’t remember if systemd can do this or not, but you can also run shepherd as a user to manage your user’s daemons (rather than the system-wide daemons). Convenient!
-
-
-
I should clarify that I meant being able to run one or more shepherd as a user being a feature :)
-
-
Shepherd isn’t an ecosystem of things that come bundled together? It isn’t Linux specific? It doesn’t (yet) slowly overtake various other components of your system, such as udev? There are definitely reasons that I still believe that Shepherd is better than systemd.
However, nothing’s perfect. Upon a further examining of the documentation, it does seem that you are correct regarding Guix’s dependence on Shepherd: namely, all services do currently depend on it.
-
-
-
-
-
What is the status of Java especially maven dependencies of a project? (which doesn’t seem to be fixed in Nix yet)?
-
-
-
We all have personal tolerances on how much we want to see other people. If my tolerance is, say, 2 hours per day, then I will have spent all of it by 10 o’clock at an open office, regardless whether I had any business with other people or not. After it has been spent, I will not actively contact people that day any more.
I think the people who design offices know this. They just care more about the costs.
-
But we short-change our customers, and we cheapen our craft, when we put up with this sort of thinking.
There’d be less money in software if we didn’t short-change our customers, and if we didn’t cheapen our craft they wouldn’t be able (or willing!) to afford it in the first place.
-
-
-
With money, I suppose. :-)
How they collect the money they invest in open source largely depends.
Google, Facebook and several other SV sell their users’ data (either directly or through corporate software proxy that let their customers use the data without seeing them, eg through advertising or fake news spreading…) Others like Microsoft monetize on some infrastructures whose adoption is challenged by free software and open source software. Other sell hardware or services based on open source software they develop, again Google but also Amazon and even Microsoft.
In all cases open sourcing software is a marketing technique: it’s a price competition dressed like a philanthropic gift.
Free software instead is an act of creative curiosity from hackers. It can be commercial, but the curiosity is the core value that lead development.
But this is another story…
-
-
-
-
-
After feeling some pain about how complicated all software, IT and Enterprise architecture toolsets are, I got this idea of a dead simple architecture sketching tool, that’s based on just nodes and named lines. The input for this tool is a text file that contains triples in the form of subject-verb-object, like so:
# comments via shebang # declare nouns (for better typo recovery) internet, web front, app server, DB, Redis # declare verbs (perhaps not necessary and may be dropped) flows, proxies, reads/writes # subject-verb-object are separated by more than 1 whitespace (" " or "\t") # somewhat like Robot Framework does it # prepositions (to, from, at, etc.) seemed redundant, so not using them internet flows web front web front proxies app server app server reads/writes DB app server reads/writes RedisI’m not married to the syntax yet, but it seems fine after a few iterations of experimentation. A tool could then read this and produce a nice graph via graphwiz. And you don’t really need a tool, you could do these sketches on a piece of paper in no time. But when you want to store and share the design, a text file + tool is a good combo.
Tried to write a parser for this language in Rust’s pest, but that was a bit of a pain – pest’s error modes are quite odd. Seems like when my parser has a problem, Pest blows up on position 0 every time. Perhaps I’ll just do a dumb line-by-line parser by hand instead. And I’d like to implement in Crystal rather than Rust. Also thought about doing it in Swift, but that doesn’t seem to work so well outside of MacOS/Linux (I’m thinking BSDs here) yet so nope.
Best part? The tool’s name is Architect Sketch.
-
-
-
This is something I’ve been thinking about a lot as well.
For my use case, I just want to dump, document, or understand how my multitude of web apps, daemons, and IoT devices all interact with one another.
I had built a rough prototype with ruby and shell scripts using similar syntax, but I couldn’t ever get Graphviz to generate a “pretty” layout for the whole thing.
-
-
Where YAML gets most of it’s bad reputation from is actually not from YAML but because some project (to name a few; Ansible, Salt, Helm, …) shoehorn a programming language into YAML by adding a template language on top. And then try to pretend that it’s declarative because YAML. YAML + Templating is as declarative as any languages that has branches and loops, except that YAML hasn’t been designed to be a programming language and it’s rather quite poor at it.
-
In the early days, Ant (Java build tool) made this mistake. And it keeps getting made. For simple configuration, YAML might be fine (though I don’t enjoy using it), but there comes a point where a programming language needs to be there. Support both: YAML (or TOML, or even JSON) and then a programming language (statically typed, please, don’t make the mistake that Gradle made in using Groovy – discovery is awful).
-
-
There is also UCL (Universal Config Language?) which is like nginx config + json/yaml emitters + macros + imports. It does some things that bother me so I stick to TOML but it seems like it is gaining some traction in FreeBSDd world. There is one thing I like about it which is there is a CLI for getting/setting elements in a UCL file.
-
-
-
-
Yep! People haven’t learned from mistakes. Here’s a list of XML based programming languages.
-
-
This leaves out a pretty important part of work: you work on a team. Increasingly it’s acceptable for people to work hours that suit them, and for many people that means coming in at 10 or 11. That means they are staying later and they are probably most productive around 3 or 4 or 5. That means they’ll be dropping the most PRs on you then or asking the most questions.
That isn’t to say that this suggestion won’t work, but you probably can’t just institute it and call it a day. The post doesn’t even mention colleagues or teams.
-
This leaves out a pretty important part of work: you work on a team.
I don’t think it matters whether you work 9-5 or 11-7. If other people on the team are working within a certain time period (such as 11-7), then by all means try to accommodate them by adjusting your hours to overlap with theirs to the extent that doing so doesn’t impact your productivity or get in the way of the rest of your life.
The fundamental principle is to do a solid day’s work in eight hours or less because unpaid overtime is for suckers. Not only are you not getting paid for the extra hours when you draw a salary, but working more than 40 hours a week reduces the amount of money you earn per hour.
-
unpaid overtime is for suckers
It’s not only stupid, but unethical too. If somebody works overtime without pay, it creates pressure for other workers to do it as well. If you do it regularly, your output gets worse, which means that your employer benefits nothing either. It’s just loss/loss.
-
I know that. You know that. Managers refuse to know it. They’d rather make wild promises, letting their egos cut checks that their own asses won’t be called upon to cash.
-
-
-
4-6 hours would be better, IMO, but I find myself turning into some kind of dirty long-haired pinko as I approach middle age.
-
I would agree if the workday were actually one solid block of nothing but writing code or thinking about writing code. However in the real world (or at least MY real world) the workday consists of that plus a whole host of scheduled and unscheduled interruptions like meetings, chats with manager and coworkers, etc.
When you add in those things, a 4-6 hour workday starts to look kinda sketchy :)
-
I don’t think it’s sketchy. I think it’s something we should have forced down management’s throat in the 1960s. In the meantime, when you add in the bullshit that comes with a coding job, you end up with an eight hour workday.
-
-
-
-
-
For teams, I think it’s fundamental to estabilish a common ground from the get go. I feel that team members should (ideally) agree on a (flexible as much as possible) schedule that accomodates everyone needs, instead of just individually decide which work hours suite them. Personally, I think that, when other team members depends on some measure of your availability, showing up “whenever you feel like it” is a sign of lack of respect for your peers (and I won’t allow it on my team).
-
My team is doing mostly 10-8 (so working more than the 8h/d). Now I usually do 8-4/5 (depending on the work pressure, my commitments, if I took an additional personal time at lunch break …) if a team member throws a PR when I have to leave, I have absolutely no scruples to let it for tomorrow. Once or twice some asked for a review when I was leaving. To that you just have to answer that you’re leaving because you called it a day and that except if it’s critical to have it reviewed it today, it can probably wait for tomorrow.
To me the teams are not an issue as long as you communicate.
-
In my experience it’s better to let important reviews wait for the morning, when my judgement is clear, rather than wave them through at when I’m tired.
-
-
Yet another reason to try for BSD jails and ansible.
If only any of the BSDs had an init system with declarable units, instead of the hack that is shell scripts.
Nobody is preventing you from installing and using one
Yes, and nobody is preventing me from using Linux with systemd either, which I rather do until they fix this. If they never fix it, that’s fine too.
How many service units are you writing on a daily basis that makes Systemd a necessity for your use case? Do Linux packages typically ship without service units and force you to do it yourself?
Well, none of the Fun parts even come from the official repos. Plus there’s of course all internally developed stuff – somebody needs to write init scripts or unit files for those. Getting a unit file 95% correct on the first try is possible.
You may be right that systemd is not necessary for anything I do. It’s just a whole lot more convenient than the alternatives.