Kudos to Meet team for supporting this! In the video conf world, where most problems are well solved, this is such an amazing feature to differentiate and be customer first!
This exaggeration of Python3 migration is ridiculous and frankly has become boring. Yes, Python 3 broke compatibility. But we had more than a decade to migrate. It definitely does not deserve to be the poster child for migrations gone wrong.
The philosophy of incompatible upgrades is brutal for popular languages, IMO.
The main issue is not that I give you X amount of time now please fix it coz you have generous time now.
The cost of such a change is ENORMOUS.
As an example, in a recently IPO'd company we had a team of engineers and we had 6 months of work for 10 engineers, round the clock, to fix the Python 2 to Python 3 migration issues alone! and the original creators of the code were long gone! .. and I could only imagine the plight of thousands of other folks in similar boats and other resource constrained boat-less entities!
Then there are distributed packages and libraries that are used by a large set of audience that are dev complete and no longer maintained as such. The cost of fixing those are much much higher.
It makes one more than wince at the thought of going through this exercise again.
The python language developers did not do it wrong. The community of python users, which include companies with ten year old unmaintained scripts, did not want it invest to transition until the absolute last second. The "Apple Solution" is to make the last second the first second. Who knows if that's the right thing to do.
The python language developers absolutely did do it wrong. You could not run mixed python2 and python3 code. Either all your dependencies were migrated and you could flip the switch and try things out, or some stragglers kept you running code with compatibilities for 2 and 3 while you waited.
And if one of your dependencies started using new features from 3.x it would break everyone stuck on 2.7, so you can't even use the new features in your library. So why would you bother migrating? So everyone was stuck in a game theoretical position where there was no first mover advantage because one straggler would invalidate all the investment.
> So everyone was stuck in a game theoretical position where there was no first mover advantage because one straggler would invalidate all the investment.
Clearly not, as most libraries are now Python 3 only, so the switch did happen.
I do see a lot of people complaining but I see no practical solutions being suggested. "Just don't do a breaking change" isn't a practical solution when the problem being fixed was such a core feature of every language, strings.
>Clearly not, as most libraries are now Python 3 only, so the switch did happen.
You don't build a convincing argument that the python developers did nothing wrong when saying this 1.5 years after python 2.7 has been EOL.
>I do see a lot of people complaining but I see no practical solutions being suggested. "Just don't do a breaking change" isn't a practical solution when the problem being fixed was such a core feature of every language, strings.
A system should have been put in place to allow python3 code to import python2 code. Then people have an incentive to actually run python3 and use python3 features.
More people are stuck on Java8 which has been EOL for a very long time. They are often stuck because Android hasn't upgraded afaik. But Java11, 14, etc can use almost all Java8 code unless it uses I think sun.misc.Unsafe or something like that. The point is that people can use modern Javas with Java libraries targeting older versions.
> The community of python users, which include companies with ten year old unmaintained scripts, did not want it invest to transition until the absolute last second.
Try shipping python3 scripts to systems that only have python2 interpreters. Doesn't work very well unless you also start to ship the interpreter and all its dependencies. I learned my lesson and just avoid distributing any Python code to customers now.
Much different from Python, though. As long as you compile your C program against the same version of libc you're running against, the program will still work, no matter how old the code. You just can't run a program that was compiled against an incompatible libc. A Python 2 interpreter can't run Python 3 code, and vice versa, no matter what, because the actual language changed.
You can't always easily compile an old C program against the new C libraries you are running. Even if you can compile it, changes in libraries can break programs. E.g. say in the ancient library, memcpy with null pointer parameters worked, if the size was zero. The new library checks it and aborts. There are all sorts of issues like this.
Every time libraries and compilers advance, you're effectively porting all the existing code. You have to fix any build breakage, and re-validate everything.
Moreover, Python is a C program. Just get the old Python 2 C code and compile it against "the same version of libc you're running" and it will work, right? Where is the problem?
Why recompile it when the existing binary still works with the current runtime? At least on Linux the old version of memcpy will still be included in the runtime library to avoid this kind of issue.
But it will run on a modern system if you compiled it against the CentOS version. I have a VM running to do just that. Trying to run Python 2 code on a modern runtime on the other hand will have the Python community feed your remains to the pigs.
> What language lets you ship scripts that use features of version X and also works on versions <X?
I didn't care about Python 3 features, but you can't run Python 2 code on a Python 3 interpreter either and the Python 2 interpreter was abandoned. Meanwhile you can run ancient JavaScript code on both old and modern systems, ancient C++ on both old and modern systems, ancient Java mostly on both old and modern systems, etc. .
> Docker tends to be the easy solution for all this stuff, and it's language agnostic.
I think I will rather go with statically linked binaries before I dump docker on unsuspecting users. Just the pain of getting that dependency whitelisted by their corporate IT makes my skin crawl.
It is not an exaggeration, the Python3 move was one of the worst releases ever in terms of managing the process. It took a decade for library creators to have it all settled. It was not end users fault that they depended on libraries that wouldn't upgrade for several years.
It is easy to look at Python 3.x today and say the migration should have been easy, but some of us were there, and remember how intransigent some core devs were about things like u"" and %, and how Python 3 offered nothing better upon release.
And it is still slower for small glue scripts. On my Windows 10 box hello, world script finishes with Python2 in 73 microseconds (the best time of 5 runs) versus 238 ms for Python3. That translates into noticeable slowdown of compilation time for a project extensively using python code in the build system.
The problem was not that Python3 had broken things. The problem was the scale of breakage and inability to use both python2 and python3 code. Moreover only after a few years since Python3 release it became possible to write libraries compatible with both Python2 and 3.
I don't agree. There are a lot of services which provide fully managed platforms with multiple competent providers you can migrate between. WordPress + CPanel does a great job at this, I've seen barely technical folks manage multiple websites and blogs,export and restore backups, migrate between providers. And this was all 10years back.
FreeNAS supports docker, so arguably, clicking download on some panel somewhere to get a working locally hosted [wordpress, game server, ...] is simplified.
"simplified" things with Docker and k8s.. if you are using docker for anything other than microservices and development environments you are doing it wrong.
Containers are substantially different to VMs, but in practice I see them as equivalent technologically and operationally for my home lab/self-hosting use cases (sans weaker security guarantees, but that I can live with).
They are a simplification in practice, because I can toss everything into a bunch of Pis that stay on 24/7 rather than worry about the power use (and the power bills) that would come with using a more fully-featured rack server/old PC that has enough RAM to deal with multiple VMs.
Containerd then? Containers predate docker in the form of VMs, the only difference being optimizations with not having to run another entire OS kernel to get software running in the exact same state on many machines in just a few seconds.
Bottom navigation bar works great for me because it's easier to use with my thumb.
I think Mozilla had to choose to either wait a long time to get full extension support and miss the train, or release early. I am also unhappy with not having the extensions I use, but I think this was the right choice. They plan to support the whole extension API eventually. Also aren't they the only ones who support extensions on Mobile?
No, Mozilla did not have to choose. They could have offered both as options! They could have allowed the end consumer to control when to upgrade (some would go quickly, some would wait until their key extensions work available). I'll admit, the majority of people will upgrade only when it's the default.
VPA is used for discoverability across UPI clients. Phone numbers can be used for discoverability among users of a single client. For eg: foobar@icici on Google Pay & baz@hdfc on PhonePe can transact with each other, but can't use phone numbers. But +91-1234567890 & +91-9876543210 can discover & transact only if they are both on either PhonePe or Google Pay or any other client application. QR Codes were initially client-specific too, but now they are scannable across apps.
UPI truly is a revolution. I can have a 6Rs chai tea (8 cents) from a road side tea stall and pay using UPI with zero transaction fees.
> UPI truly is a revolution. I can have a 6Rs chai tea (8 cents) from a road side tea stall and pay using UPI with zero transaction fees.
The main benefit of UPI is that it works really well for small amounts, e.g. the INR 6 tea. Such small transcations were traditionally too small/uneconomical for Visa/Mastercard.
However as the transaction size grows, say you're buying a laptop for INR 50,000 -- that's when the protections Visa/Mastercard build in against fraud start helping you and UPI's "no transaction fee" value proposition also starts looking like "no accountability".
Interestingly, India has a home-grown Visa/MC alternative called RuPay, which also waives transaction fees for small amounts and is a credible alternative to Visa/MC.
Unfortunately Indian startups have been obsessed with pushing e-wallets (PayTM et al) or direct electronic cash transfers (UPI) because it benefits them -- as the transaction size goes up it certainly doesn't protect the consumer.
You can have phone_number@paytm or phone_number@bank as you vpa is you prefer that, also UPI API, you can search users with phone number so if i want to send money to a friend and I know his no I can search his VPA/s
Everyone not happy with pocket recommendations, what is the alternate source of revenue? Not enough will pay for the product. On the other hand Mozilla has to compete with Apple, Google & Microsoft, all of whom are fighting hard for the Web.
Mozilla is doing good overall. They are doing some fundamental work to get back the technical edge, still trying to keep the future of the platform open with WebAssembly and their products have become much more reliable now. We have to cut them some slack.
I will be honest, I used to be a very active Pocket user as soon as it got bought by Mozilla, hoping that Mozilla would have open-source a significant part (in not all) the tech behind Pocket (so I could use my own install if wanted) and because the personalized recommendations it provided were very relevant to my interests.
Sadly, Pocket hasn't become open-source nor has it kept its awesome personalized recommendations.
They could use the donations to improve Firefox, to pay the salaries of the engineers, instead of all the political nonsense they do with the foundation. Yes, your donations go towards that.
And they could cut the salaries of management instead of giving themselves raises.
I don't think you get what I said. I said: if they stopped throwing money down the drain with the politised foundation and the executives stopped raising their salaries they wouldn't have to run ads and maybe they could even pay their engineers more money.
Can you elaborate on the ways in which you feel the Mozilla Foundation is politicized? Their advocacy page[1] feels incredibly vanilla: it emphasizes private communication, online safety, and collaboration with generally well-regarded groups like the EFF.
First that's her. Then I am going to entirely ignore yoir pointless jab at developers. The discussion was strictly about Baker 150% raise.
The 2017 deal was a 8% increase in revenue. That's a significant slow down of the increase trajectory of these deals. Meanwhile every other metrics were going down, most notably market share.
2017 also saw the rebranding and the Pocket deal go through. I still don't think it was worth a 150% increase.
I find it to be rather well-written for this sort of thing. As in, it was written with an intent to communicate what it's saying, which is the opposite of the usual.
When Pocket was first introduced in Firefox, the official party line was that it was just something temporary donated by the good people of Pocket to plug a feature hole so that you, dear users, won't suffer much while we develop a proper replacement.
And now this has somehow transformed into a vitally important revenue stream?
Having a secondary revenue other than Google's donations is not a bad idea. Some of us actually like Pocket. My only wish for Pocket to handle links to PDFs
Great to see GitLab gain momentum in FOSS. It's a great fit for small teams too, it's easy to setup and keep updated. It's more important than ever to help GitLab gain adoption with GitHub making it free for private repos. I love GitHub as much as any developer, but I believe having a free, open alternative to it is important.
I wish GitLab would improve their free-version of Merge Request reviews though, Github's is much much better right now.
I'd love to hear more about what you dislike about merge request reviews. At work we've been talking about migrating looking for alternatives to GitHub over dissatisfaction with its code review interface, and, of course, GitLab is on the list of ones to check out.
Ability to review diff between two versions of PR is a great missing feature in GitHub. When dealing with large changes, GitLab review flow is IMHO easier for reviewer. Gitlab store each push of a MR branch as different version (as hidden refs), which make the feature possible. In GH, you force push a branch, you loose the old code for good, so reviewer has to remember why he did that comment before to see if it is still relevant.
This is such an important feature that has a direct impact on code quality and time savings that I'm not sure why it isn't a priority feature. As a reviewer, having to choose between "review everything again" or "trust the submitter didn't introduce extra changes in the revised pr" is such a terrible choice to have to make.
In the top left, there should be a "changes from..." drop down menu that will let you choose which commits you want to view. The default is "changes from all commits".
If you're on GitHub Enterprise, availability will depend on the last time your company has installed updates.
That is not the same feature.
It requires you to always add your fix in a new commit add opposed to amending the commits and maintain a clear purposed commit list.
I think the more official Git way of doing it would be to collect all the changes in separate commits, and then squash merge them at the end of the code review.
In my experience, GitLab's MR UI really lacks performance when the diffs pass a certain length. Similarly sized diffs in GitHub don't seem to have this problem, though.
I think of it as additional incentive to maintain smaller patches for ease of review, but sometimes changes are necessarily large due to complexity. It can be obnoxious to be hamstrung like this.
Honest question: isn't it far better to review the patch locally on your laptop? I always do this, primarily because I like to be able to go through the callers of functions that the patch modifies, look at the callers of functions that have been introduced, etc.
My decades-long complaint with every single code review system I've been forced to use at my workplaces (which no system I've seen fixes so far) is that they don't let you browse code and examine the diff in its native setting, so to speak.
I mostly like their merge request UI but one big missing feature for me as an easy way to view and review commit messages. For complex patches the commit messages can be vital.
One thing I find annoying and occasionally hazardous about Gitlab merge requests is that per-file diffs which exceed a certain length are collapsed by default. This introduces risk since it is very easy for a reviewer to skim right past the collapsed file name, since one's eye tends to be drawn to the more salient red/green diff.
I have developed a habit of going through my own pull requests immediately after opening them, and adding a "don't forget this file" comment to all the ones that get collapsed.
'Cuz yeah, I've seen some nasty stuff sail past code review simply because it's so easy to accientally miss those files.
Good one, I'm going to do that too, thanks. It's pretty nuts how broken a UI is that it forces us to do stuff like this though.
I feel like everything about the GitHub PR UI is targeted at reducing the code review job to being a human style checker. Minimal context, no code navigation, abysmal rename following.. it's really hard to review the design of a change.
The reason for the automatic collapse is due to performance. Also it's not uncommon (depending on the language and framework you are using) for the biggest files to be just a mere dependency lock file kind-of update.
Code search, Gitlab doesn't have a code search feature. Paraphrasing The code search functionality can be achieved by adding Elasticsearch. We haven't added elasticsearch yet so cannot comment on the experience of using it.
Our current approach is to make code search available for Bronze/starter and above.
We appreciate your feedback on enabling it for non-paid.
This is the Epic we are working on, feel free to leave feedback here as well.
https://gitlab.com/groups/gitlab-org/-/epics/1736
Although not at GitLab.com scale, I've worked on a few search-related projects (often using Elasticsearch) in the past and would consider offering some ideas.
Does GitLab have a policy for attribution/licensing of technical design input from external contributors? (this is partly out of curiosity in general -- I don't know for sure whether I'd have anything to add that your team wouldn't already have thought of themselves)
Merge requests seem to merge both branches in to each other. This is not the behavior I would expect. It doesn’t seem to be that way on github but I could be wrong. I see this behavior when to long lived branches are merged.
My git-fu is average level so its possible that I’m missing something obvious here. For me the easy solution is to just merge on the command line.
Does anyone else have things that make the switch from GitHub to GitLab a hard sell?
I'm always curious why open source projects don't embrace an open platform, although I get that GitHub is fantastic in a lot of ways. I'm guilty of it myself, but I've reached the 50/50 GL/GH split as I try using GL more.
I don't think there's any one single blocker that's keeping me on GitHub. It's just a bunch of little annoyances with GitLab that add up to make it not worth it -- either UI quirks, or ways in which third-party tools integrate just a little more easily with GitHub.
Yes, GitHub absolutely has a bunch of annoyances, too. (I listed a bunch of them here on HN in response to a question by Nat, just the other day!) If everyone were using GitLab first, we'd probably find excuses to put off switching to GitHub, too.
To attract users, you've got to have a pull. If that's "open source", then it needs to be a way in which the closed-source nature of GitHub is hurting my daily workflow. If it's "user interface", you need to be such an improvement over GitHub that it's worth the cost of switching. If it's "cost", that's tough because GitHub dropped prices and is now $0 for many users, and you probably don't want to get in a price war with Microsoft (see: Netscape).
It doesn't have to be the same pull for every customer, but every customer needs at least one.
"We're just as good as that big popular project" isn't a pull. I've seen hundreds of projects try that, and it never works.
This sums up my attitude towards it. Opportunity costs factor into switching cost; am I getting enough ROI for the switching costs vs something else I could be working on?
The community edition is a castrated mess with ads in it. I administrate a gitlab instance for a university and gitlab is hurting me in so many ways.
1) it had a message that tells you that the elastic search is so much better and that your admin can enable it (if he would only switch to enterprise)
2) it pretends to have functionality only to have it hidden behind an "available in ee" banner
3) it has a new functionality where it annoys everyone that has a new ip (24h disconnect anyone) that can't be disabled (only through patching) and suggests that enabling 2fa helps, but is send regardless of 2fa
And every function that gets cut out and hidden behind the enterprise banner iy forever lost to you, because even if you implement it yourself it will nevet get merged since the function exists, in enterprise...
Ps yeah there is a free enterprise license for universities, but it is not available for staff or external users (other universities) and the licensing model is so unflexible that you can't mix "free for students" and "pay for staff" or "students get enterprise" and "staff get basic features"
Pps I had to patch out more than one thing over the years this was just the first thing that came to mind
Thanks for the feedback on the GitLab for Education program. In the spirit of iteration, we started the program as an MVC - offering free licenses for teaching and learning related purposes. The program has grown significantly since then and through meaningful feedback from our members, we’ve come to realize the structure is not ideal for Universities to implement at an enterprise level. We have an epic open to restructure the program and welcome constructive input. https://gitlab.com/groups/gitlab-com/marketing/community-rel...
Thanks for reaching out through hn. I will take a look at the epic you linked. Those are indeed many issues we faced (and other universities as well. there was even a discussion of somehow trying to license one github instance for all universities in the state although I'm not sure if this ever amounted to anything)
I'm really interested in the development of this issue so thank you again for reaching out.
Ok I can't edit my original comment so just to clarify:
GitLab doesn't serve ads it only pushes out messages to users that they could have a better product if only the admin would shill out some bucks.
It's ok if admin settings are greyed out with a remark like in old freewares to tell you features you could have in the enterprise product, but if the software tells any user that they are missing out it is more unnescessary work for the admin to explain that we don't have the money to pay for every single student, most of which only create an account without pushing any code, just so that the search can work over all wikis and not only the selected one.
So again it's more like the "buy winrar" or "go pro now" nag and _not ads_. Sorry for the confusion
> The community edition is a castrated mess with ads in it.
I understand your frustration with FOSS pushing you toward buying proprietary software.
But your lede will mislead people into thinking CE gets revenue by serving up third-party ads because that is what "ads" mean for web services 99.99% time the term is used on HN.
I called it ads, but it really is more the promotion of enterprise features and yes it is "new" since it only started popping up in the last year or so. It also seems that they are trying to dial it back, but gitlab really started getting aggressive with annoying little things like that and is getting on my nerves from time to time.
On a positive note it got quite a bit more responsive in the last 4 or 5 five years since I started hosting it and even thought we got some regressions and bugs and problems with releases we didn't have any data loss (that we know of) or major security problems. Most of the security problems are in the enterprise functionality anyway (elasticsearch and grafana pop up regulary)
Sorry since I only provide access to students, faculty and collaborating universities (so no open registration) I never needed antispam functionality, but can't remember seeing any entry in the administration interface or config as well.
I truly believe it's because github has become a social network and developers use it as popularity contest. They want their commits to be there just like influencer wants to be on Instagram not on my fairly unknown platform.
I can confirm, this is the exact reason I made two copies of (shameless plug) the SpicaStack project earlier this month. GitHub's reach, network and stars help fellow devs and users discover our forks, while GitLab's exportability and amazing CI will let us actually work on it.
I use multiple hosts to backup my repos: I host gitolite.org on a $5 VM and then have it configured to automatically push to gitlab and GitHub on every change.
Absolutely - people now ask to see your Github repo as an integral part of your CV without even really considering if you might use another service.
And you don't exactly want to pitch to them how you don't have your code on Github because you use this other "fringe" service which even if they look at it they are going to find unfamiliar.
I now host 50/50 on Gitlab / Github because I'm not really affected by this, but I'm conscious of it.
I use Gitea for my own projects, i.e. I do the setup myself and it's trivial. It uses SQLite as backend, so no complex DB deployment.
It's very easy to deploy, consumes few resources (you can run it on a low-end VPS). It even has Jenkins integration.
However I don't know how it scales to big teams and projects since I only use it for myself.
And I'm not entirely convinced by its security track record, but it looks like things are improving.
A Turing complete language executing unsigned code in a sandbox that allows HTTP and HTTPS requests to 0.0.0.0/0 and ::/0 is not something everyone wants in their life.
It's not a hard sell, but it is certainly an inconvenience. I prefer to browse with javascript off by default and only enable it for sites that absolutely need it. I've had issues where sites using JS have caused a single core on my laptop to spin at 100% thus affecting battery life negatively.
In some cases "I'm browsing GitLab" might be the exact impetus for someone's attempt to disable JS. As noted above, GitLab is sluggish. I was an early adopter/advocate for GitLab, but you can feel the bloat on every page and I no longer use it.
Gitlab CI pipeline was a deal breaker for our organization. Lots of UI bugs, quite a few issues with CI nodes hanging, and ultimately their yaml job configuration system turned out to be too constrained for our needs. We eventually switched back to github and jenkins. This was more than a year ago though, so I expect some of those issues have improved during that time.
Product director for CI/CD here - we have tried to focus on improvements around making more complex pipelines easier to manage, but I would love to hear what you ran into just to make sure we are closing the loop on all the important ones.
I like GitLab and GitHub quite a bit, but I lean toward GitLab for the simplicity of a unified tool chain.
However, I think GitLab can only really shine when you host it yourself. In 2020, on-premise/self-managed anything is kind of a hard sell, but the reliability and performance of gitlab.com leaves a lot to be desired. (So much so, I often think about trying to work for GitLab so I could help from a reliability perspective.) I stuck my neck out for GitLab in a previous organization and we ended up migrating from github.com to gitlab.com. This set me up for some embarrassment for every outage they experienced last year which felt surprisingly frequent. But if you have the resources, self-managed GitLab is great!
1. The selected Java SDK API desugaring, though limited, is much awaited. Little things like supporting `java.time` up until API Level 14 make it less painful, don't have to end up using Joda Time even though it officially is not developed anymore.
2. Good to see Google focus on animations finally
3. The CPU profiler looks amazing
The transition to androidx has been slow and painful. But overall Android dev experience is improving consistently
Can you cite some examples where UI animations aren't counterproductive, annoying, amateur-hour crap? Swiping screens away to convey a stacked hierarchy is useful, but beyond that I struggle to imagine what I'd do with them.
There's a reason we hated Flash-based Web sites, and animation was a huge part of it.
Now I'm considering which is worse: animated UI, or transparent UI. The asinine transparent-UI fad largely and deservedly died in the '00s, with the exception of Apple suddenly jumping on its discredited and defunct bandwagon years later.
Don't see why we need to bring back animated UI either, but I'm happy to consider suggested uses.
Speaking of stacked hierarchies, the rotatable 3-D display of views in a UI might be pretty useful. I like that idea.
