Lots of people just don't game at all. Also, a lot of people like me prefer different gaming and work setup (and different rooms) in order to achieve better work-life balance. I build games on my M1 machine, just don't play on it.
How is M1 for game dev? I've been thinking of getting one for my own personal laptop, but have had a few concerns, mostly just due to the issues of building software on a totally different platform to the majority of your target users (which'll be Windows, x86). I used to have some compatibility worries but I'd guess they've gone away now.
If you are using a game engine like Unity you should not worry at all. If you need to access Windows specific APIs, of course it is a different story.
A Macbook is a perfect machine for developers: you can build for android and iOS, has a great screen, perfect touchpad, finally fixed keyboard and ports.
I use Godot at the moment, but have been experimenting with frameworks like Bevy and the like. I doubt I need immediate access to windows specific api as I currently work on Fedora without any issues, though from what your saying it sounds like you mean more mobile-game dev than desktop.
To be honest the last time I used a mac was I think a decade ago so they're just so unknown to me at the moment, but everyone else seems to love them so I'm quite tempted
What are the specs of your machine?
If you've tried them, how have have other engines such as Unreal fared?
Do you primarily do 2D or 3D development?
How long are the build times?
It depends on the type of game you're shipping. Not every library has caught up to offer a mac arm binary. You still see some Rosetta problems here and there.
You can't dual boot so you can't natively run the game you're working on. The graphics are integrated so you can't test on a PC GPU. VR dev doesn't work at all.
Lots of small things but if you also have a PC its not so bad unless you need some library that just doesn't work.
But it is different for the author. He learned to love himself after his girlfriend showed her love to who actually he is. So lots of people struggle to love themselves because they never experienced what does it mean being loved.
My two cents on this add a difficulty level. 1370 characters to 500 characters is too difficult to many. Reducing 300 characters to 150 characters would be a better starting point for me.
DevOps become center part of Gitlab which we don’t use and need any of those feature. We all need a code storage, code review, issue tracking and the CI/CD. We would pay advance features of those (epics, multiple assignee, etc) but we have to pay super expensive top tier which includes unnecessary DevOps stuff. We left and happy so far.
We are using Kubernetes and custom DevOps tools but don’t want to handle things the way that Gitlab does.
This is happening everywhere. The current industry cycle is one of scope expansion, moving away from the do one thing well paradigm. This will lead to bloated software that do a little bit of everything but not very well, which will trigger the next industry cycle, of doing one thing well paradigm.
Ive started working with Gitlab in last few months for new contract and this was exactly what hit me hard.
Gitlab has too many half-baked features. Ive hit those issues at least a dosen times.
From the top of my head:
- Environment variables dont work with triggers
- MS Teams integration does not support multiple channels
- Masking doesnt work for all variables
- Code AutoDeploy quite often just breaks for no reason..
- Kubernetes integration is super poor
I would prefer to have fewer fearures that actually work well and have good support instead of bunch of stuff you have to sometimes wait years for to be fixed (looking at their issue tracker).
GitLab Product Leader here - we do focus on MVCs and have built a lot of breadth in our product, that's something we are proud of. I do think we do a good job of pivoting and removing features where appropriate. For example we started with a not-secure-enough mechanism for attaching Kubernetes clusters and shifted to the more secure GitLab Agent for Kubernetes[1], deprecating the certificate method. We also started with a "must install Prometheus and Elk on your cluster" Observability solution and are now (after our acquisition of Opstrace) working to make observability on-by-default[2].
Hello - I am the product manager for GitLab Runner. The SIGTERM-related issues have been quite complex due to the different execution environments in which the Runner can operate. Can you add the details of your use case and workaround to the issue below? We need to take another look at this functionality, given the various reports of inconsistent behavior with long-running processes.
CentOS7. I've also asked the SCM team at my employer to get us added as a paying customer who would like this looked at, to help prioritize.
I don't know if you just need to do process groups or walk the subprocess tree or what... but generally, this is a solved problem on Linux for things that manage subprocesses... assuming the processes don't manually do something silly like daemonizing themselves. (That's not my use case.)
Linux should be the easiest case.
edit: What is most frustrating is this issue appears to have been opened ~4 years ago.
I really love GitLab, but I agree it has too many half bake features, and too many features that are wonky.
We use GitLab at work, and I tried hard to push back against the hate for it, but its hard sometimes when GitLab is just WEIRD, especially in simple things like MRs.
Yeah this is a really bad direction for gitlab. All of their devops features are terrible. They don’t pay their engineers which is why everything is poorly built.
They should have just focused on being the best vcs. Oh and you get what you pay for. Want to hire a bunch of mediocre engineers? you’ll get a bunch of half baked features
I'm honestly of the opposite opinion. I have used GitLab for 10 years now and have yet to find something as useful as GitLab's CI/CD, and I've tried (not always by choice) a ton of different options.
Mainly it's because I strongly prefer to orient most of my flow around Kubernetes deployments and namespaces tied to git metadata like commit sha or branch name, and thus far, I haven't found a better more interested way of doing so than GitLab.
I think you're mistaken. DevOps is a very specific team allowed to touch the Jenkins box, and is the old branding for what is now SRE which are both just rebranded names for Systems Administration, but with Cloud certifications instead of Cisco and Dell.
I kid. But this is just as much the meme I've encountered as Agile. Some successful company releases a book about something they do that's fundamentally different, and almost instantly enterprises across the globe have a department for that thing with that name. Progress.
Real SREs are great. Who wouldn't want a Systems Engineer that codes and can interrogate kernel issues or a Software Engineer capable of writing their own compiler running your operations?
Most companies, even if they hire these people, don't know how to use or listen to them though. What usually happens is they get lumped in with a bunch of Application Operations folks and it sours the idea entirely.
Yeah, this. There's a gulf between people like Brendan Gregg (my go-to example of a "Real SRE") and those I've actually worked with, who anointed themselves with the same title...
As a side-note, is any tech group more keen on title inflation than SREs? In the time I've been a developer / software-engineer I've seen sys admin, DevOps, Cloud Ops, SRE... it's literally the same people.
> As a side-note, is any tech group more keen on title inflation than SREs? In the time I've been a developer / software-engineer I've seen sys admin, DevOps, Cloud Ops, SRE... it's literally the same people.
That's not the fault of people doing the work, that's what the industry is doing to us.
I get increasingly irritated with the myth that 'DevOps' are any different than the sysadmins of 10 years ago.
"But DevOps can code", yes, so could sysadmins, in fact, terraform, ansible, vagrant, saltstack, chef, puppet etc;etc;etc are all made by people who held the title of sysadmin when they were written.
In fact the term "DevOps" was originally from a conference, where the idea was that "we can do systems administration in an agile way" -- NOTHING to do with coding, everything to do with getting developers and sysadmins working closely together in an iterative fashion.
I would personally be very happy being called a sysadmin, but doing so is career suicide, because we as an industry have decided that sysadmins are somehow braindead, and that you really need "SREs" or "DevOps" -- despite the fact that these are the same people.
What gets my goat even more is that people hate on sysadmins because of corporate culture, echos of centralised IT organisations that said no to everything.
But we're doing exactly the same thing with these new titles now. It's a joke.
Your comments really come off as bitter. I think this maybe just says more about the companies you've worked for than anything else. SRE is a methodology and a pretty-well understood methodology at this point.[1] The actual title is less important than the practice. It also goes by different names at different companies, example at FB it's called Production Engineer.
By the way Brendan Gregg is a Performance Engineer not an SRE. I believe that's been his title for close to 20 years, according to the the bio in his books. I don't believe he has ever had the title SRE.
That wasn't my intent. I have done my share of DevOps, it's not for me. Maybe SRE would be.
> I think this maybe just says more about the companies you've worked for than anything else.
Yes, it does :)
> The actual title is less important than the practice. It also goes by different names at different companies, example at FB it's called Production Engineer.
Absolutely. I'm just saying that I've worked with people titling themselves SRE who aren't doing the stuff of that methodology. When last years DevOps team starts styling themselves as SREs but nothing else changes, then they have definitely missed the point about the methodology being the thing that matters!
It's not just those teams, of course! There are plenty of "fullstack engineers" who wrote a Node function one time.
> By the way Brendan Gregg is a Performance Engineer not an SRE. I believe that's been his title for close to 20 years, according to the the bio in his books. I don't believe he has ever had the title SRE.
This seems to be true, but he's spoken at SRE events on "my SRE work at Netflix".
Well, I was trying to clarify this statement from OP:
> DevOps become center part of Gitlab which we don’t use and need any of those feature. We all need a code storage, code review, issue tracking and the CI/CD.
It reads to me like this: "We don't use DevOps features in Gitlab, but we use CI/CD pipelines in Gitlab". So it is contradicting. As they responded, CI/CD is a subset of DevOps methodology.
I've used Gitlab and didn't know there were more DevOps tools other than their CI/CD features and runners.
DevOps is whole set of tools. Gitlab includes features like monitoring, code scanning, Kubernetes integration, docker registry, cloud security and protections. And those are $1188 per year per person. By CI/CD I mean good old Jenkins that runs on a computer in the office that builds iOS Apps and uploads them to Apple AppStore (of course current generation of CI/CD is much better). Gitlab CI/CD and runners were there much before this "Gitlab is the one DevOps platform" saga.
Everyone in our company including HR, marketing, design people were also using Gitlab for task tracking. Therefore we need those fancy issue tracking features for better management. This features are in the tier that $1188/year per person. For the features we don't use is not something that we could afford.
I thought the OP was maybe referring to Gitlab's "AutoDevOps" features which were introduced a few years ago. From their site:
>"GitLab Auto DevOps is a collection of pre-configured features and integrations that work together to support your software delivery process."
I remember upgrading a Gitlab instance at that time and ended up with an issue that was the result of the AutoDevOps feature set. It seemed that AutoDevops was turned on by default. My issue was easy to resolve but I remember thinking at the time it was rather opinionated.
Is it really "center part"? I'll admit there is some unnecessary clutter here and there, but it's easy enough to ignore.
What I don't understand is who these features are for, and who uses them. We use the CI/CD parts, but other than that manage everything through k8s, and I wouldn't dare let GitLab a handle it. And, the whole "one click devops", or what it was called, is even more puzzling.
Neural Engines may be used in CoreML models. I don't know it can be used with Apple's BNNS library [1]. You can use with TensorFlow Lite with coreML delegate as well [2]. And some tried to reverse engineer it and used it for model training [3].
Google added one of my employee's LinkedIn account address as our LinkedIn URL to our company Google business profile. We have contacted google support about this to change URL to our own but we got response like following:
I understand that you are referring to an incorrect LinkedIn profile which is visible under your business profile in Google. Please be informed that information from social profiles are collected by automated algorithms.
There's no way to manually remove these social profiles from our end. This is something which is driven by Google’s algorithm, based on the visibility, ranking, web presence, etc. of the particular business page. We at Google do not have any manual control over this.
Google and its algorithms are going bad and they have no control over it. It is getting ridiculous.
I didn't understand NFT storm as well then I made a 10K collection of NFT images with my friend (I wrote the smart contract) in three weeks and earned $3M from that. I made a lot of money and now I'm part of the creator community but I still sometimes ask "Why?"
