That is more or less correct. It is a way for state governments to enable "their side" to win easier. It will get worse as the demographic shift continues to strangle the GOP's support in swing states.
There are plenty, but there are also definitely a lot more on the Republican side. A majority of self-identified Democrats favor legalization, while a majority of self-identified Republicans are against: https://today.yougov.com/topics/politics/articles-reports/20...
> "Pretending it isn't a partisan issue is silly."
The stats to which you refer don't support that dismissal.
In that survey, 50% of Dems supported legalisation/decriminalisation (which you'll notice is not quite a majority, or is a narrow one if you ignore the undecideds) and 34% of Republicans supported it.
So it's a 16 percentage point difference. Yes there's more support among Democrats, but not so much so that you can dismiss it as a partisan issue.
Anecdotally, here in Australia, someone I know very well works in a government policy role administering sex work, and some of the most strident campaigning in favour of re-criminalisation comes from the left. In this state it was a conservative government that legalised it in the early 90s, in the first year they came to power after 10 years of social-democratic government. There's no campaign from the conservative side to re-criminalise it here.
1. Market makers don't make investment decisions or hold positions. They facilitate trading as counterparties to investing parties, but do not drive prices themselves.
2. Market makers would make a terribly poor shadowy cabal, because the amount of capital they collectively manage is in the high single to low double digit billions. Mutual funds, hedge funds and private equity account for trillions.
Management made demands that exceeded resources available and kept blocking my vacation to try to meet deadlines. I literally left with 100% of my vacation accumulated.
Technocrats lack the skill set to win elections where everyone lies outrageously.
If they had such skills, they would be common American politicians. One if the few benefits of China's collectivism is all the politicians have to share the same reality, even adjusted by party propaganda. It allows technocrats to operate effectively since they do not need to compete with outrageous liars.
Is it about lying outrageously? I grant that occurs in high-profile and memorable cases, but is the average race for the house or a local seat corrupted by outrageous lies? It just seems sensible and historically continuous that those who study the law (lawyers) end up being the ones who most frequently write the law. I am 100% for more STEM and humanities-oriented law-makers, however I'm arguing technocrats lack specific knowledge of laws, not of lying.
Do you genuinely believe that when many laws are written by interest groups and past with little modification?
And yes, the average race us corrupted by outrageous lies. I have literally never seen an election at any level that lacked outrageous lies by at least one of the candidates.
> The investment is no longer substantial in public R&D.
The US is spending over half a trillion dollars per year on R&D total, and the Federal Government is spending $113 billion - every year - on R&D. How is that not substantial exactly? A trillion plus dollars every ten years is a lot of R&D.
The US total spending on R&D as a share of GDP is about 40% higher than the EU and is about 30% higher than China's current ratio.
China's total R&D spend, between public and private sectors, is around $260b to $300b. So the US Federal Government all by itself is spending ~37%-43% of what all of China combined is on R&D. That's substantial.
Currently on an inflation adjusted basis, Federal spending on R&D is as high as it was in the late 1990s. There's a fair argument to be made that it should be perhaps $50 billion higher. Federal spending on R&D nearly doubled during the Bush Administration, and then flat-lined under Obama before declining in the last few years of his Presidency. If you continue the spending expansion of the Bush years, it would add up to around $50-$60 billion more.
The problem? The US has an inbound trillion dollar budget deficit, 2/3 of which consists of entitlement costs ballooning ever higher. Business spending on R&D has massively expanded in the last 30 years, going from $60 billion up to $360+ billion or so. To an extent I'm ok with that arrangement, the government can focus on more important things like entitlements. The $113 billion per year in Federal R&D is plenty to put toward long-term projects that the private sector isn't funding.
The ability to recognize key areas to build up capability is not discernible in absolute R&D numbers (it looks like FY2018 there is about $140B planned in total R&D). The other thing about your numbers is that we need to know if there has been a purchasing power adjustment to make them comparable.
With respect to the US Gov't R&D, you don't mention that about 50% of that R&D is for defense. Personally I would argue that a bigger split to non-defense uses would yield pragmatically better "defense" of the US. Of the non-defense funding, much of it goes to "FFRDCs" Federally Funded R&D Centers. There is this game that the US plays with liberal (in the economic theory sense) firewalls where we have increasingly bought into this ideological stance that the gov't should never compete with private interests. In contrast, I would guess that China's R&D went much more directly towards creating new industries. I think China is being much more pragmatic about it's R&D expenditures than the US.
GitLab should, frankly, focus on performance/ux/bug-fix releases every other release. And probably for the next 2-3 releases to get some of the warts under control.
This constant push for project management features, frankly, is at the expense of the core product. I'd rather use a combination of GitHub and JIRA over Gitlab.
I have a feeling that many people who constantly ask for "fixes" are the kind of people who want to "fix them all", by rewriting without understanding that it is a never ending cycle.
Don't pay attention to them. Just do your thing.
Gitlab has provided the much needed competition with real impact (consider Github boards, for example) and you have a company that can pay many people a living. That is more than good enough.
Thank you very much for the encouragement, I appreciate it after significant commenting today while flying from Mexico to San Francisco. You can rest assured we'll keep working on our vision https://about.gitlab.com/direction/product-vision/
The people that ask for fixes care about GitLab and are worth listening to. There is an almost infinite demand for new features and we can't make them all (even with more then 2000 open source contributors). But I've found that Hacker News readers have great insights and we'll keep listening and adjusting were we missed the mark.
I just wanted to add that I have been absolutely loving gitlab. Signed up in 2014 and use it pretty much daily.
One of the biggest problems I had was the speed of the web ui but since the great github migration the speed increased massively and has stayed snappy.
Contributing code to GitLab has also been my favorite experience with open source as not only were my changes looked at, Gitlab developers actually helped me get things working and write better code.
There is a lot more work to do and we'll keep shipping performance improvements in code and to our infrastructure. The tentative date for our migration to GCP is next weekend.
I'm so glad to hear that contributing code to GitLab was a favorite experience! Kudos to our merge request coaches who try to get every merge request over the finish line with a high quality.
I just want to let you know that I code just for hobby, super simplistic projects like notes app, javascrtipt utilities, personal blog on Jekyll etc, gitlab @ davchana, I absolutely love Gitlab, and have been using it since almost two years.
Before it I always had to find a free hosting, with lot of shaddy banner ads or unreliable systems. Gitlab.com free edition has everything I wish for, & occassionally I read & wander in gitlab.com issues repo just to see & be amazed on new improvements being made. Being a completely remote company is a cherry on top.. Great Work!!
They can also measure it live in the website, the median response time of API calls and so on.
Github has said this:
"We’re quite obsessed with performance. We want to make sure the site is always performant and continually fast. For a Rails app, github.com is a really, really quick site and we have a motto that “It’s not shipped until it’s fast.”"
https://medium.com/s-c-a-l-e/github-scaling-on-ruby-with-a-n...
They can create a performance measurement team, assign tickets based on what they find and prioritize them as part of ticket management. If something is too slow, then maybe it's time to refactor the underlying architecture or subsystem thats making things slow.
When glaring security issues sit open for a year, you need to understand GitLab is a problem for anyone who has regular security audits.
I am not asking for 100% redirection of resources to fix all the issues. I am suggesting they reprioritize resource allocation to lean more towards fixing issues that exist instead of new feature implementation.
It's not obvious to me that that's a glaring security issue. If the password were encrypted, then Gitlab would need to be able to decrypt it, so all you're gaining is a bit of security through obscurity. Which doesn't accomplish anything when it's a publicly documented feature of an open source project.
I'd agree that, depending on usage model, this isn't a major issue, in that if you symmetrically encrypt a password, you still need to store the key somewhere to do the decryption.
That said it is possible to improve the security of this kind of model, although there is a trade-off in availability. What can be done is that the decryption key (or a passphrase controlling access to it) is stored offline and manually input at application launch.
The downside is that if the application restarts it needs human intervention to be operational. the upside is that you reduce (but not eliminate) the risks of the credentials being compromised from that system.
They have both SaaS and self-hosting options which cost considerable amount of cash ($99/mo per user for the most expensive option) for any large scale deployment. They're earning plenty and they need to fix what is valuable to their customers.
It is blocking people from converting to paying customers because as soon as we see an issue like that we know it isn't viable because we'll get denied.
If you have not done so already please ask our support team if they have an alternative solution. I've heard of people dynamically loading secrets but I'm not sure it addresses your use case.
Merge request page load times. Sometimes it can take like 5s for a merge request page to load (and then another 5s for the comments), and that's noticeably more frustrating than github's snappy UI. 5s isn't world ending but it is obviously slow and frustrating.
Treat server responses taking over 100ms as failures and keep fixing that.
There isn't 1 thing that's wrong, it's the entire UI, every operation that feels like it has a lag. Using GitLab is like using an app via remote desktop. It's tiring.
I am not here to push any specific ticket. I just think GitLab should move in the direction of redirecting more resources to fixing the warts as a general policy decision.
Ultimately, I am not your customer and haven't been for a couple years so it is up to you.
I don't know about the performance and bugfix issues, but based on my experience with gitlab.com, I don't think it has a good UX design.
You see, there are many many best practices in the UX world, just like those in the programming world. And seems to me, GitLab is not following many of them.
For example, the width of the content area.
I've once read an article that trying to dig into that topic, and one opinion that article has brought up was that users eye should not move too far up and down and more importantly left to right. I deeply agreed with this because I found myself feel very tired after reading a width page.
The solution is of course to limit how width the content area is, according to many factors (front size for example).
Now if you look at the user's home (project list) page on the GitLab, you will found that the page and the list (which is the main content) has been designed to fill 100% width of the view point.
On the left side of the list, is the name and description of my projects, and on the right side is the counters + update date.
The information on both left and right side are significant, so I may have to scan it from time to time, and it's exhausting.
If you're thinking, "Oh it's just the user's home page, no big deal". No No No, the search result page is the same deal, same design language.
Now, if you take look GitHub, you will found that they're not only limited the width of their page, they've also limited the width of the project list by adding a sidebar on the page. Which makes me 10 times more comfortable when using it.
Also, since we're talking about project list already, let me also remind you that the front is also very important.
Currently on the project page, the project name text is bold'ed, and underneath it is the description text. Problem is that the size of both text is the same, which makes them muddled together when doing a quick eye scan. GitHub on the other hand, use white space, front size and color to differentiates those elements which makes their list far better.
I did a little re-design to the project list to clarify what I've meant.
And these just two examples, there are many of them. So please GitLab, design your web interface better. I'm currently mainly use your product now and I don't want to have many struggle with it :)
Thanks so much for the feedback, the UX team here at GitLab is always looking for ways to improve the user experience. It looks like someone else in this thread mentioned that you can choose between a fluid and fixed layout depending upon your preference. Some prefer a fixed width and others hate wasted screen space. We try our best to accommodate everyone.
Given that, we agree that this can be improved. We have an issue here discussing page-width, https://gitlab.com/gitlab-org/design.gitlab.com/issues/47. As you can see, in many cases we have decided that we should reduce the width in order to improve readability. I will add a link to your comment in the issue as further data on our user's preferences.
Also, we opened an issue with your suggestions for the project list page. Feel free to jump in and add any more thoughts you have there, feedback is always welcome. Here is a link: https://gitlab.com/gitlab-org/gitlab-ce/issues/49504
Thanks for your feedback around content width. Making GitLab accessible on all screen sizes is important to us given that there are many users out there using HD (720p) screens primarily. Our design indeed has fixed width portrait container enclosing the page body (with maximum size being 1200px) so here's how it looks on a large monitor at 100% zoom: https://i.imgur.com/lTqL6X8.png
Hence if the browser viewport width goes below 1200px, page body ends up taking full width. Although this screen resolution being still widely used, I've opened an issue to discuss this further here https://gitlab.com/gitlab-org/gitlab-ce/issues/49488
So, hi kushalpandya, jmiserez and svesselov (For some reason I cannot reply your comment)
Looks like you guys didn't understand what I just said: The problem is the UX design is NOT very good. I think you guys should re-think about how user will interact with your interface.
For example (since I discovered the 'fluid' setting): Even if a user have a super wide monitor, when the user turn on the fluid setting and maximized the browser, should they saw an interface like this: https://screenshotscdn.firefoxusercontent.com/images/324e117... ?
Also, from my point of view, 1200px is still too wide for that list. If you take look the version that I've modified, you will notice it's only about 400px wide, and with that width, I can scan every results on the page without moving my eyes too much.
The magic thing is, with 400px, YOU can also scan every results on the page without moving YOUR eyes too much, even your monitor is wider than mine. And THIS, my friend, is the so called compatibility. The goal here, is to provide the same level of user experience -- GOOD user experience, NOT to fill the whole width so the page look like the same in every resolutions.
Again, the key point here is NOT about just the width of the page, it's not a problem between 400px and 1200px and 100%, it's about how you guys think how users will feel about the UI -- Will user feel tired when using it? Can the UI effectively helping user to get what they want? etc.
If you have no idea, go checkout some list designs on https://dribbble.com/ (By the way, dribbble.com itself is very well designed, go learn from it)
Don't worry though, I'll keep using your product and patiently waiting for improvement :)
There already is an option to set this, at /profile/preferences:
Layout width
> GitLab can be set up to use different widths depending on your liking. Choose between the fixed (max. 1200px) and the fluid (100%) application layout.
I agree. Our team test drove gitlab earlier this year (as in, moving all repos over and using it for a month). We were hoping to consolidate a suite of products into one unified dev hub. )sadly, we found the general clunkyness and slowness a deal breaker for us. Lots of clicks to perform actions, each click requiring a short wait. Many features that applies to single projects don't apply to groups. We felt the core features were still very unfinished, especially when working with multiple repos. We looked at the roadmap and decided to move on.
Gitea has been very close to core Github Features IMO and Gogs (the original fork) has some neat other features separate from Github.
There is also Bitbucket which does integrate neatly into JIRA in my experience.
There is a lot of choice, Gitlab is great if you need a "everything in one box" solution for every problem or demand you might encounter during development.
Other Git-Webapps solve other problems or problem spaces.
I think saying "for economic reasons" doesn't really paint the whole picture.
It's not just about "growing the economy", it's about ensuring that the economy is strong enough to support the population as it ages people out of the workforce.
