Yup. It’s good enough if you’re already invested in docker for dev and good enough if you’ve out grown a single machine. But not big enough for more than 10 nodes and user roles.
From an ops point of view it’s simple to deploy and I’m yet to hit any really sharp edges. However the lack of cronjobs and init containers is an annoyance, but you can work around them.
Mirantis’ recent announcement of further dev on Swarm after the initial announcement of only 2 years of support has not helped. I had been looking at moving to k8s. I’m now undecided if we should just continue with the plan to dump Swarm or keep it.
> but rejecting any kind of innovation isn't something I am willing to do.
I don't think the post you're replying to is really saying "no innovation". I think it's more subtle.
The "problem" with DoH is that you need to look at it with several different hats, and I feel very few people make it clear how they're complaining about DoH.
* From a consumer perspective DoH is a good thing (mostly)
* From an traditional/enterprise/business-like environment perspective it's inserting itself in the middle of the stack and may cause headaches with a few things (not limited to leaking internal names to external resolvers), unless it's just blanket disabled/forced to a local server (which may not always be practical for different reasons) - currently
Ultimately who do we have to blame for this but ourselves? Organisations have tried to get encrypted DNS off the ground in traditional DNS infrastructure and clearly failed to meet the required timeline.
I personally feel like the problem, just like with IPv4, is that traditional DNS infrastructure is "fine" (i.e. it works). We don't have a great motivation but we do have fear of breaking the many many many boxes which are un-upgradeable/critical.
nomad, k8s, mesos+marathon (or something plus mesos), traditional deployment
That's probably about it. Right now, I'm jumping on the k8s bandwagon, but looking to keep it simple. As much as I'd like to look at nomad seriously, too many times I've been caught by not looking at the mainstream.
My personal experience with MSSQL drivers (ORMs and lower level) for many younger, non-Microsoft endorsed, languages is that whilst they will work you will get caught with sharp edges. Until several years down the line and enough people who have the will/time and consolidate their efforts. That said, even MS official endorsed libraries can suddenly disappear (I'm looking at you msnodesql).
Having been down this path, without the time to dedicate fixing/working on a driver, I wouldn't even consider a non-"blessed" language in combination with MSSQL anymore. It was too much pain.
I’ve been working with Odoo for about a year implementing it for a small-medium business in the UK (lots of customisations, general specing out etc, working with their partners, etc. So not all dev). Disclaimer I’ve not yet touched v13.
The good; The OCA (community association), the people (both community and Odoo), the basic framework gets you up and running fast. You can tell it’s grown over time, and it’s got sharp edges, but you can get what you need done. Not necessarily in the prettiest way. The backwards compatibility and desire to not break the core APIs is generally good from what I’ve seen so far. Individual modules depends how much Odoo themselves lean on it afaict. GitHub access for partners and direct source access to both enterprise and community editions has been extremely helpful.
The bad; imho testing is a pain. The ORM uses Polish notation to build filters, which if you’re used to SQL is frankly irritating to work with. The ORM itself is quite clever, but it’s also not like any ORM I’ve worked with. The dev docs aren’t great, beyond the basics. The quality of modules in the “App Store” is extremely hit or miss. Odoo official “support” as a partner is questionable. I feel like they’re under pressure to get you to pay up to be a partner and then some period of time you might get help later. Anecdotally I’m led to believe our partner account manager has been pushing us hard to host a local event at our own cost (I’m not that involved with that side). The last few versions have seen more accounting features drop out of community edition. Some of the official apps are basic.
Is it better than SAP, Dynamics, etc.? Probably not. Is it good enough given the price point and flexibility, for smaller businesses? Probably, especially if the business has been tying together lots of apps adhoc.
You should also checkout ERPNext (https://github.com/frappe/erpnext). Its another free and open source ERP (GNU GPL v3) which is not open core. ERPNext is also built as a monolith, so you get maximum features out of the box instead of relying on 100s of extensions to fulfill your requirements. All since there is no "enterprise" version, there is no chance of features dropping out like accounting and payroll.
ERPNext has reasonable traction too (~5k+ stars on GitHub, 12k+ forum members) and is used by some very large enterprises.
You guys should definitely dial down on the marketing hyperbole. A good technical getting started documentation would be much better than forcing potential users to dig through GitHub and stumble their way in.
V12 saw accounting reports, and iirc budgets and assets moved to enterprise. I saw a tweet I can’t lay my hands on right now from
an OCA member about additional modules being moved in V14 (for context V13 was only released a few weeks ago, so things may change)
If they move components to enterprise in a new version, how hard is it for the community to fork the last open source version of those components and port them to work with the newer version?
That has happened several times already. The best known fork is probably Tryton, which forked during the OpenERP transition. It has seen a lot of independent development since then, also with some sort of company backing. (I evaluated it many years ago so my experience is probably no longer relevant.)
It would take an experienced odoo Dev to fork and maintain it. And they would also have to take the huge amount of business requests and support questions.
I worked on developing a module last year. I see a number of issues, most are shared with many "platform" applications.
Somehow you see especially "enterprise" software being written as a kind of proprietary platform, often like a kind of jvm or .net clone, with some half-baked ORM and lots of moderately documented (at best) infrastructure ("framework" ugh, usually feels like a straightjacket), on top of which one can develop "modules" that are all intertwined and create a dependency hell and a huge dependency on the proprietary platform.
I don't see the point. There are enough open platforms that are at least as good to create "enterprise" functionality, including database frameworks etc. Why would one use a proprietary framework that you have to adapt to, instead of a general purpose platform with some libraries that you can pick and choose from?
I had my fingers in SAP, a lot, some Odoo and tried out Dynamics 365 for my startup. SAP is great for larger companies or even smaller ones if they resist the urge to customize the ship out of SAP. Can't say too much about Dynamics, only that without manufacturing there are more specialised WMS and TMS solutions out there.
Odoo on the other was just a big pain. None of the workflows was automated. The consultant had no idea how goods receipt works. Not sure how much of it was the fault of Odoo and how much was due to a bad installation and bad custumizing. Regardless, this experience kicked Odoo of my list potential ERPs right away.
I was until even a few years ago still in the camp of progressive enhancement. I'm now accepting that you really do need Javascript and you cannot get around it. It does bother me that we've swung so far towards SPAs.
Beyond deeply dynamic webapps, such as ERPs/line of business apps, and the very few that really do need offline mode, I think server rendering in conjunction with javascript is the right path.
What that looks like in today's world I have mixed feelings about.
Phoenix's (Elixir) LiveView (which is now being duplicated in as Livewire in PHP) is an interesting take and certainly fills a gap, but I'm getting that feeling of jQuery era where markup is peppered with magic attributes. And equally it doesn't address all use cases (which is fine).
The simplified timeline (as I understand it, willing to be corrected if I'm wrong);
1. PIR, or someone very close, seems to have lobbied to have price restriction of .org removed. My understanding is that PIR made the argument that they're a non-profit, they have no reason to raise pricing extortionately
2. This was passed, despite a large number of comments against the idea, Ethos was incorporated the following day
3. PIR sold itself to Ethos, a for profit company
The people involved seem to be moving between ICANN, PIR and private firms.
Given all these things I don't think it's unreasonable that people are deeply sceptical. Especially with the ambiguity of "no more than 10% per year" being throw around.
You forgot the part where Ethos is the same people who controlled PIR. It’s just a sleazy trick to take off the non profit veil, so they can start skimming the profits. Does anyone really believe the non profit PIR and ISOC couldn’t exist on their $90 million a year .org tithes?
This is what is more properly called incestuous relations between corporations. This will only serve those companies and people be-bopping between them with shadow titles. I don't know if this guy owns part of those companies and is benefiting or one of his bros at those companies convinced him with his "for the greater good" bullshit that MBAs learn in school.
You don’t need high base pricing to keep domain sharks away. Some throwaway alternatives that are less workable, but already seem fairer:
You could limit numbers of domains per entity, or increment the price for each new domain you buy.
If you try to buy a domain using a company with human directors it is 10x the price.
If you buy a domain with non-person owners (e.g. a shell company) then its 100x.
As an aside: I wish more things were taxed or priced higher based on the obscurity of the entity purchasing the item. It’s no cakewalk, but it still feels too easy for those with the resources to use company and legal structures to be able to act with a disproportionate lack of public scrutiny.
Seems about right to me, this stinks of whatever the non-profit version of regulatory capture is. I wonder how hard it would be to make a parallel ICANN.
I guess this is naiive, but how can a non profit sell itself to a for-profit, it seems all sorts of wrong.
I was running my own mail server for nearly 10 years on Hetzner. Prior to that on other hosts and in the distant past at home. Running mail servers is something I have done professionally and successfully.
The last time I moved boxes as I had many times before. I was on clean IP range but I had no IP reputation at all. In the past this wasn’t such a problem, especially with SPF, DKIM, rDNS, DMARC, server-to-server SSL etc. Around the same time I started having to deal with organisations (legal, etc for a death in the family and later rent) rather my my own circle of friends. It became extremely apparent that my mails weren’t hitting the inbox. But they were being accepted. This was extremely problematic.
I was in the group stating that running your own mail server isn’t hard. I still say that. The hard problem is convincing the big players to let your low volume domains and IPs hit the inbox. I begrudgingly gave up my MX servers last year.
I wonder if there's some sort of relay setup that could be used to mitigate this: e.g. if you want to run your own mail server, sign up for some kind of "mail ring" that transparently proxies the (encrypted) traffic from all the member mailserver administrators. That way, your public IP has a higher volume and more leverage getting delivered.
Integration with SPF and would be unfun and probably even impractical (max 10 lookups iirc?). I’d also worry about the inevitable abuse which would appear to originate from your range(s). If you can mitigate those though, it sounds interesting
How well does the auto wipe behave on Tesla’s? I’ve owned multiple cars with the feature over the last 10 years - the only one which has ever got it close was a Lexus (quite some time ago). The rest I’ve had and still need to constantly police.
What I want next is an automatic sunscreen that slides down based on sensing the angle of the sunlight. I think there is also technology to dynamically darken glass that could be used. I hereby grant a free perpetual license to auto manufacturers to use this idea. :)
> I think there is also technology to dynamically darken glass that could be used.
Looked into it previously. Even if you got it to work, it likely would not be street legal, as there are pretty strict regulations on what part of the windshield can or cannot be tinted.
I haven't had to manually turn on the wipers, but I have had to turn them off on one or two occasions when the computer _thought_ it was raining for some reason.
It's behaved very well for me. There was only one instance when I was in a drive thru that it wiped the window even though it was dry, not sure if it was because the angle of the sunlight hitting some dirt or something.
From an ops point of view it’s simple to deploy and I’m yet to hit any really sharp edges. However the lack of cronjobs and init containers is an annoyance, but you can work around them.
Mirantis’ recent announcement of further dev on Swarm after the initial announcement of only 2 years of support has not helped. I had been looking at moving to k8s. I’m now undecided if we should just continue with the plan to dump Swarm or keep it.