[HN Gopher] Apple contributes to OBS to support screen capture u...
___________________________________________________________________
Apple contributes to OBS to support screen capture using
ScreenCaptureKit
Author : jiripospisil
Score : 637 points
Date : 2022-01-28 09:42 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| syspec wrote:
| Before / after side by side comparison video:
|
| https://user-images.githubusercontent.com/65677710/151421432...
|
| --
|
| (This and 2 other videos are linked in PR conversation tab:
| https://github.com/obsproject/obs-studio/pull/5875)
| DoctorOW wrote:
| The weird thing to me is that it's not just lower CPU/GPU for
| OBS, but lower GPU for the game. Maybe just a coincidence,
| since the CPU fluctuates so much between the two.
| perryizgr8 wrote:
| I wonder if this will provide a way to hide the yellow dot that
| appears in the corner (to indicate mic access). It is a great
| idea in most cases, but quite annoying to see on screen
| recordings.
| clock99 wrote:
| hendry wrote:
| Makes me wonder how efficient Xorg vs Wayland capture is on Arch
| btw
| shantnutiwari wrote:
| Maybe OBS will work on my Mac now. I struggled to get it working,
| everything recording as I wanted. Thought it was just "crappy
| open source" stuff, so gave up.
|
| Some time later, I tried OBS on Windows, and it just worked,
| first time, no fiddling required. And I realised the problem was
| on the Mac side, not Obs.
|
| I know, its just one anecdote.
| symfoniq wrote:
| Between one and two years ago, my team had serious issues
| getting OBS working reliably on T2-equipped Macs. We switched
| to an expensive commercial product and all our problems went
| away.
|
| I couldn't duplicate the OBS issues on older Macs that didn't
| have the T2 chip.
| sprkwd wrote:
| Getting the audio to work on MacOS OBS is always a pain.
| j_koreth wrote:
| Personally I had luck with using Blackhole
| TillE wrote:
| It shouldn't require a third-party driver! It's basic
| functionality which should be provided by the OS in a
| userspace API.
|
| Blackhole does its job, except your volume buttons stop
| working when you're on a multi-output device. Quite a pain.
| Johnyma22 wrote:
| Adding to the anecdote, OBS works great on Ubuntu.
| xd1936 wrote:
| How long ago was this? They've been making some big stability
| improvements over the last year or two.
| pilif wrote:
| This commit in the PR
|
| https://github.com/obsproject/obs-studio/pull/5875/commits/8...
|
| provides an excellent example of why commit messages matter. This
| is more than 1000 lines diff to the build system (and thus
| potentially very dangerous because of possible supply chain
| attacks) which has the commit message of
|
| "CI: Update build scripts and Github actions workflow"
|
| Never say what you ware doing (it's obvious this commit is
| updating build scripts). Say why you are doing it, _especially_
| when your commit feels unrelated or at most very tangentially
| related to the objective of your PR.
| donatj wrote:
| We have a rule internally that a PR can't be more than 1,000
| loc. I personally find a 1,000 loc PR almost unreviewable. It
| takes me multiple days and a stack of notes, and still almost
| always ends up with effects I didn't anticipate.
|
| Trying to understand the changes and their full implications is
| nearly impossible. 100 loc is a better top end imho.
| dlsa wrote:
| Code reviews are interesting to watch. Especially when the
| author awkwardly pauses and says, "I'm not sure what this
| code does".
| Cullinet wrote:
| about days and a stack of notes :
|
| this is why we have line printers, custom reading tables with
| balanced soft lighting (print proofing lamps) and more
| recently, rostrum cameras operated by foot switch.
|
| review with fanfold might be a habit only acquired by
| formative experience, but once you physically manage the
| printout, and are comfortably seated with several hundred
| well spaced lines that aren't directly emitting typically
| exhausting spikey spectrum light forcing your brain to
| perform extremely complex colour management to balance your
| vision, which is the primary factor in concentration
| depletion in every attempt at testing we've tried over the
| years, and you mix in modern handwriting recognition and a
| pico projector display of feedback comments if necessary, I
| have only witnessed very high productivity. Anyone who is
| subject to audits will know the satisfaction of dumping
| fanfold boxes on the auditors desk. Or should.
| coldcode wrote:
| Last place I worked (big company, not FAANG) I remember a PR
| for our main app that affected 500 files and occasionally
| dozens of places in some of them. All the reviews were
| "LGTM".
| ascagnel_ wrote:
| I forget where I first saw it, but there's a joke of "ten
| lines, ten issues; 1,000 lines, looks good". There's a
| human limit to how much you can hold in your head when
| reviewing code.
| whimsicalism wrote:
| I think it's a double edged sword - people are also way
| too nitty for small commits, which only incentivizes
| behavior like this.
| sockpuppet69 wrote:
| thetallstick wrote:
| Looks like the programmer's version of: "If you owe the
| bank $100, that's your problem. If you owe the bank $100
| million, that's the bank's problem."
|
| https://www.goodreads.com/quotes/214064-if-you-owe-the-
| bank-...
| doix wrote:
| When you refactor a commonly used structure, it's easily
| possible to hit situations that you described. In those
| cases, having nicely organized commits are super important.
| You need to make sure that the commit that does the
| refactor _only_ does the refactoring. Nothing else, then
| you can review the PR commit by commit and it becomes much
| more manageable.
|
| When people start doing multiple things in a single commit
| with 1000's of changes, it does become mentally exhausting
| to review. Unfortunately, it requires either being
| extremely diligent when making the commits or being
| familiar with git rebase -i.
|
| Of course, sometimes it's just thousands of lines of new
| code and impossible to review :).
| lulzury wrote:
| 10 lines of code = 10 issues. 500 lines of code = "looks
| fine."
| travisgriggs wrote:
| Parkinson's Law of Triviality
| rlt wrote:
| HN: big tech companies should contribute more to open source!
|
| Also HN: no, not like that!
| i386 wrote:
| Seems pretty fucking clear based on the message to me.
| n3_ wrote:
| In this case it looks their work is based on another branch not
| yet merged (https://github.com/obsproject/obs-studio/pull/5155
| which adds support for Apple Silicon) - and the commit is from
| there.
| Applejinx wrote:
| Looking forward to that: I'm going to be needing to use OBS
| on Apple Silicon.
| mikkelam wrote:
| I honestly thought it already was running natively, it
| already runs super smooth in rosetta
| ziml77 wrote:
| Rosetta is incredibly impressive. And I guess it needed
| to be. The switch to ARM was going to be a hard sell
| without a fast x86 translation layer. I'm hoping though
| that devs don't use it as an excuse to never release ARM
| builds of their software. It would be good to have ARM
| builds across all the major operating systems.
| krallja wrote:
| Github can point the PR at that branch and those commits
| won't show up anymore.
| timdorr wrote:
| That branch is on a different fork (PatTheMav's), so they
| wouldn't be able to do that in this case.
| da_chicken wrote:
| Yes, and the author was _asked_ to base the PR on 5155:
|
| https://github.com/obsproject/obs-
| studio/pull/5875#issuecomm...
|
| And it looks like they're just going to set the PR to a draft
| until after 5155 is merged, so it will get cleaned up and be
| easier to review then:
|
| https://github.com/obsproject/obs-
| studio/pull/5875#issuecomm...
|
| HN is usually better about sussing out the real story.
| steerablesafe wrote:
| Just to chip in what should the commit message say: it should
| express the intent of the change and the reason of the change
| (latter could be reference to ticket). I don't think expressing
| how the intended change is achieved is important, that's what
| the diff is. If it's not clear in the diff how the intended
| change is achieved, try adding some comments.
| disintegrator wrote:
| I'm all for well presented PRs/commits but I'm not sure how a
| good commit message mitigates the risk of a supply chain attack
| in this case.
| pilif wrote:
| It might help the reviewer to not flat-out reject the PR
| because it gives them a fame of mind as to what the intention
| of the change is.
| rkangel wrote:
| > Never say what you ware doing (it's obvious this commit is
| updating build scripts)
|
| DEFINITELY say what you are doing. And _then_ say why.
|
| This blog post is a good description of the most prevalent
| convention in how to write good and useful messages (e.g. this
| is what the Linux Kernel does and given the history of git
| there's some flow down): https://cbea.ms/git-commit/
|
| The key thing that means you should start with what is having a
| short one-line summary of what you're doing so you can look at
| a simple log and see which commit you're interested in.
| jldugger wrote:
| > DEFINITELY say what you are doing. And then say why.
|
| My favored github PR template has 3 sections:
| - What does this PR do? - Why is that valuable? -
| Link to bug tracker.
| ihaveajob wrote:
| We have a similar template at work, and since we made it
| the default (on Bitbucket you can pre-fill it), it's saved
| a ton of back and forth asking questions:
|
| * Description: (What this does, and why)
|
| * Ref: (Ticket/task link)
|
| * To test: (Specific instructions to make sure things are
| working as expected)
|
| * To deploy: (What specific servers/services to restart,
| and operations to perform)
| pferde wrote:
| Also, if your commit message has parts that say "also, this",
| "also, that", don't be lazy and break those alsos into
| separate commits!
| jacobmischka wrote:
| Not necessarily. It sounds like all of the things mentioned
| in the commit message are interconnected (updating build
| scripts and updating gitignore to remove the new build
| directories). It would be pointless to break these into
| separate commits, you can't revert just one without
| reverting the others.
|
| The commit message is lazy, but breaking these into
| separate commits because of some "also" rule of thumb is
| just blindly following a rule for the sake of it.
| capableweb wrote:
| > breaking these into separate commits because of some
| "also" rule of thumb is just blindly following a rule for
| the sake of it
|
| Agreed, cargo-culting is always bad!
|
| But, without knowing how OBS development team works,
| sometimes it does make sense to split commits like this,
| mainly if you have a larger repository where different
| people are responsible for different areas in the
| codebase.
|
| For example, build-scripts sometimes gets managed by
| other people than the ones writing some core algorithms,
| who are also different from the people writing public
| APIs to be consumed by users. In those cases, it makes
| reviews a lot easier when you can split out to review
| different commits to different people, instead of having
| everyone navigate the same commit.
|
| But again, not familiar with the internals nor the
| development cycle that OBS keeps, so maybe this doesn't
| make sense in this case.
| threeseed wrote:
| As others have mentioned many times here.
|
| This commit is based off a branch that was adding support
| for Apple Silicon.
|
| So the entire PR is not going to look clean until that
| branch is merged first.
| capableweb wrote:
| Yes, makes a lot of sense. Sorry if I gave the impression
| that I think somehow this PR is wrong or similar. I was
| just replying to the fact that sometimes splitting up
| commits makes sense, outside of this PR.
| rlpb wrote:
| My exception to the "also" rule of thumb is that if the
| split changes would cover separate areas of the code such
| that each piece could be easily picked out by "git add
| -p", then splitting them out isn't required as long as
| they are all associated to one logical larger story.
|
| > ...you can't revert just one without reverting the
| others
|
| That's often true in a split out patchset anyway, so I
| don't think that on its own it stands as a justification
| for doing things one way or the other.
| Cthulhu_ wrote:
| Dubious. I prefer that style myself, but there's a lot of
| value in squashing multiple commits around a feature into a
| single, "this commit implements this feature" commit. Is it
| valuable to retain the entire development history of a
| feature, or just the feature itself? What if during the
| development, it was rewritten a dozen times? What if
| there's a dozen commits where the author meandered and only
| in the last three commits got to the point?
|
| Ruthless interactive rebase is one way to fix that last
| point, but if you take the final result and squash that
| into a single changeset, there's a point to be made about
| that as well.
| pferde wrote:
| Agreed, it's a matter of preference, but I prefer
| logically separate changes to be in separate commits at
| least within the PR, where it may make reviewing the PR
| easier. It's basic empathy towards the reviewer(s).
|
| Of course, when merged, it often makes sense to squash
| some commits together, just like you say - long-term,
| many of the feature development details are not
| important.
|
| It's not an either-or proposition.
| Cthulhu_ wrote:
| Small nit: Maybe not say what YOU are doing, but what the
| COMMIT, when applied, will do. Git is not a personal work
| log, it's a source code change log. A commit may be a
| collaborative effort; it may be a squash of a thousand
| smaller commits; it may be a merge, it may be generated by a
| tool (like the dependencies), etc.
|
| The commit should summarize what IT does, not what YOU did.
| In ten years, nobody will care who you are or what you did,
| but they will care what the code does and why.
| MrGilbert wrote:
| That's the main reason we are using present tense in commit
| messages, not past tense. It's the commit that is applying
| the changes at that moment.
| thaumasiotes wrote:
| > That's the main reason we are using present tense in
| commit messages, not past tense.
|
| As a linguistic note, commit messages (at least, English
| commit messages) almost always use an infinitive verb and
| therefore may be considered to have no tense at all,
| though to argue that infinitives have no tense you do
| need to draw a distinction between tense and aspect.
| zestyping wrote:
| Ironically, the referenced article on how to write good git
| commit messages (https://cbea.ms/git-commit/) gives no "why"
| for most of its points. It lists 7 rules, of which 2, 3, 4,
| 5, 6 are simply declared without rationale.
| pixiemaster wrote:
| so true.
|
| my personal observation: because writing down ,,what" is
| hard. Writing down ,,why" is even harder.
| ignoramous wrote:
| > _This blog post is a good description of the most prevalent
| convention in how to write good and useful messages._
|
| See also:
|
| https://google.github.io/eng-
| practices/review/developer/cl-d...
|
| https://microsoft.github.io/code-with-engineering-
| playbook/c...
| michaelt wrote:
| Doesn't the gigantic pull request description [1] already
| provide ample description of why the changes are being made?
|
| [1] https://github.com/obsproject/obs-studio/pull/5875
| kzzzznot wrote:
| That doesn't get stored in git, you won't be able to see that
| information on the clone of the repository you will be
| developing on locally.
| timdorr wrote:
| It's in the commit message, so it will get stored:
| https://github.com/obsproject/obs-
| studio/pull/5875/commits/5...
| gwd wrote:
| Just to expand on that, I always say there are three
| audiences for the commit message:
|
| 1. The reviewer
|
| 2. Someone scanning commit logs for patches of interest
|
| 3. Archaeologists
|
| Archaeologists are people a year, five years, 10 years down
| the road who are trying to figure out how the code got to
| be the way that it is, so they can feel confident changing
| it. (See also "Chesterton's Fence"[1].) Those people should
| not have to dig out the conversation from some random PR to
| figure out what's going on.
|
| [1] https://news.ycombinator.com/item?id=30070757
| cdcarter wrote:
| Isn't the PR exactly where you'd go to see that
| information, if you're an org that uses PRs to store that
| information?
| whimsicalism wrote:
| > Those people should not have to dig out the
| conversation from some random PR to figure out what's
| going on.
|
| Not knowing to look to an associated PR thread for a
| commit would be the equivalent of modern day
| archaeologists not knowing what "carbon dating" was.
| plorkyeran wrote:
| A fairly common occurrence when looking at old commits is
| that any URLs mentioned are now 404s, and ticket numbers
| are for an issue tracker that no longer exists.
| progbits wrote:
| None of that is part of the Git repo, so any mirrors won't
| have the context.
| madmoose wrote:
| It's in the commit message:
| https://github.com/obsproject/obs-
| studio/pull/5875/commits/5...
| ff133 wrote:
| Question from a naive kiddo; When the PRs are this big, what
| are the steps taken to "get it in" the master ? Just blindly
| accept based on CD/CI jobs, or break it down to walk through
| every change ? "Ref: supply chain attacks"
| pilif wrote:
| If I was in the position of having to review that PR, I would
| probably flat-out reject it and ask for just the minimal
| changes required.
|
| I don't see how adding an additional capture framework
| backend would require meaningful changes to the build system.
|
| With some likelihood, in this case, Apple probably won't have
| the resources to rework their PR and thus the PR will stay
| un-merged until somebody of the project has time to
| merge/reimplement the relevant parts.
|
| Which of course is a total shame and I wonder why Apple
| didn't have "mergeability" in mind when they decided to
| create their PR. They must have known that "rework the build
| system" can't be part of a PR adding a capture backend if
| they wanted any chance of this being merged.
| pbhjpbhj wrote:
| >Apple probably won't have the resources to rework their PR
| //
|
| Aren't Apple the richest corporation in the World, how
| would they not have resources; am I missing a joke? Maybe
| you meant 'will choose not to'?
| Cullinet wrote:
| I didn't get where I am today by employing engineers with
| my profits...
|
| Before three was Dallas, there was The Rise And Fall Of
| Reginald Perrin, in the main arc a dark parody of 70s
| corporate England. If you could find a better audio-
| visual exposition of the transatlantic difference at the
| end of the nineteen seventies, you will struggle to find
| a funnier one.
|
| http://www.leonardrossiter.com/reginaldperrin/CJisms.html
|
| https://www.google.co.uk/search?q=reggie+perrin+i+didn%27
| t+g...
| spockz wrote:
| It is not that uncommon to have make changes to a build
| system in many places in order to support a new
| architecture. Especially if there was previously only
| support for a single one.
| Diskutant wrote:
| No, the PR is based on another PR [0] which adds Apple
| Silicon and Universal Binary builds, the mentioned commit
| is part of that PR.
|
| [0] https://github.com/obsproject/obs-
| studio/pull/5155/commits
| madmoose wrote:
| The Apple developer's commit builds upon another pull
| request which contains the build system work by OBS
| developers, the build system changes are not part of
| Apple's commit.
| kristjansson wrote:
| A million comments and this is the only valuable one.
| Amazing that everyone accepted the premise that Apple
| proposed refactoring some other project's CI.
| fnord77 wrote:
| in the description of the PR, there's almost 1000 words of text
| describing in detail what is being done. I don't see the
| problem.
| ricardobeat wrote:
| Note that those commits seem to have been added by an OBS
| contributor _on top_ of Apple 's patch. The fact they touch the
| entire build system, in a PR that is 100% macOS focused, is
| much more concerning than the commit messages.
| emptybottle wrote:
| Yes, a good commit message should be a few concise paragraphs.
|
| The subject describes what is being affected (think easily
| greppable keywords)
|
| Then, then body should go into detail about the contents and
| rationale for the changes.
|
| Use specific terms like "add" or "remove" and avoid subjective
| descriptions like "prepare" "clean" and "fix"
|
| For example this patch says:
|
| > Clean up consistency of tabs/spaces in include_directories.
|
| Well, what does clean up tabs/spaces actually mean? Saying
| "remove tabs in favor of spaces" is much clearer.
| avipars wrote:
| Nice to see them contribute to open source!
| programmarchy wrote:
| In the PR description, if you expand the sections "Baldur's Gate
| 3 Demo", "Shadow of the Tomb Raider", etc. it shows the
| performance improvement of capturing the respective games. Looks
| like a very significant improvement.
| jagger27 wrote:
| I want to know if they're using Rosetta on their M1 test machine
| or running it natively. Hopefully this patch leads to a proper
| darwin/arm64 release so I don't have to use this weird fork[0]
| with a private GitHub Action to get a native build. The Rosetta
| version is considerably slower.
|
| 0: https://github.com/carlosonunez/obs-installer-for-apple-
| sili...
| lelandfe wrote:
| > _I want to know if they're using Rosetta on their M1 test
| machine or running it natively_
|
| Natively.
|
| There's an open PR[0], #5155, to get OBS native on Apple
| Silicon. That's also what your weird fork uses.
|
| Apple's PR is on top of that work: you'll see that there are 10
| or so initial commits. Thus #5155 will need to be merged first,
| before Apple's.
|
| #5155 is a huge PR and has been open for 5 months. Its release
| will also necessitate OBS get an M1 testing solution figured
| out. Here's a quote[2] from an OBS team member two days ago:
|
| > [This PR is] top of our priority list once we release 27.2.
| We're keenly aware of how badly people want a native Apple
| Silicon build, and I can assure you that we will definitely be
| publishing official test builds of OBS with M1 support as soon
| as we are able.
|
| I would nevertheless expect for all of this to take quite a
| while.
|
| [0] https://github.com/obsproject/obs-studio/pull/5155
|
| [1] https://github.com/obsproject/obs-
| studio/pull/5155#issuecomm...
| jagger27 wrote:
| Thanks!
| deweywsu wrote:
| Oddskar wrote:
| I find this PR an interesting opportunity to discuss different
| types of documentation.
|
| I've internalized that there's a difference between the PR
| description, commit messages, and code comments. For me there's
| different intended audiences for all three, and their contents
| should thus be shaped accordingly. This PR basically combines all
| three into one and uses that as the commit message, and I'm not
| sure of what to make of it. Is this good practice?
|
| Personally I find the contents of the "#### Summary of Changes"
| list to be super-neat and helpful. But should these not be more
| helpful as comments inside the code? On the other hand, it _does_
| explain what the code is doing at this snapshot in time: which
| makes it more precise than comments in the code -- since future
| changes might eventually make those comments incorrect.
|
| What's your take?
| edgyquant wrote:
| Personally I like for the dev to do little commits that
| document each change to a file and then when the branch is
| merged in you do a squash merge and each commit msg becomes a
| bullet point.
| clone1018 wrote:
| For anyone trying to find the actual changes made, vs the build
| system that was modified, you can find them with this compare:
| https://github.com/PatTheMav/obs-studio/compare/universal-bu...
|
| The branch on GitHub should change its reference until the build
| system is merged into the main branch.
| twelg wrote:
| acomjean wrote:
| ScreenCaptureKit seems to Apple only, so this only helps Mac
| users.
|
| While nice it seems to be a trend where Apple seems to contribute
| to open source projects now to improve its own performance only
| on their own devices (blender comes to mind). Maybe Im being a
| bit cynical.
|
| Still a positive I guess.
| gumby wrote:
| You are indeed being too cynical.
|
| The point of open _source_ (not just a free binary blob) is
| that you can fix the parts that matter to _you_.
|
| In the case of companies, they typically work on the parts that
| matter to them. This has been true since the free software
| movement started to reach into businesses, with companies like
| Cygnus (of course) but also Sun, SGI, IBM etc all working just
| on their own platforms.
| acomjean wrote:
| That's a fair point. I haven't looked at their contributions,
| but it would be nice if they'd help out the project as a
| whole as well.
|
| I also got a Linux preinstalled conputer, so I'm hoping
| (selfishly perhaps) that open source projects have great
| first rate open source OS support. It seems like open source
| is always resource strapped.
|
| But you are right it's not like IBM, SGI, Sun weren't
| proprietary..
| gumby wrote:
| NeXT funded and performed quite a bit of open source
| software, quite a bit of which continued in the Apple
| transition.
|
| Make no mistake: for all of these companies, this funding
| was in support of their commercial activities. They have no
| desire, say, to write a shell so if one is popular they'll
| go that way. One thing we taught then in the 90s was that
| stepping off the mainline simply added to your support
| cost; this lesson is why so many proprietary companies do
| contribute back.
|
| Apple's case is interesting: they think more deeply than
| many about this. Thus they are enthusiastic about standards
| when they are weak in the domain: e.g. Apple was explicit
| up to the Jobs level that they embraced open standards like
| JPEG and MP3 when trying to dig the Mac out of a deep hole;
| once they had a solid foothold they felt comfortable trying
| out proprietary formats. They went USB-C (and handed over a
| majority of the work on its design to the USB consortium,
| or so a couple of friends who worked on the standard
| claimed to me) because it helps adoption of the Mac and
| iPad; but aren't afraid to make a MagSafe connector.
|
| It's all about strength and weakness to Apple, an approach
| which frankly more companies should adopt (looking at you
| MediaTek, AllWinner and your competitors).
| pigbearpig wrote:
| Having Apple contribute in the area of their expertise makes
| sense.
|
| Are they supposed to contribute the Windows 11 screen cap?
| outsidetheparty wrote:
| While I see what you're saying, to be honest it seems pretty
| reasonable to me for Apple to contribute work that helps Apple.
|
| Many OSS contributions are "scratching your own itch", no?
| ninkendo wrote:
| I mean, it's not a bad engineering philosophy for things as
| low-level as this to be provided by the OS as a framework.
| Capturing screen output at a high refresh rate without
| introducing lag may be better implemented with lower-level
| access to certain system components, in a way that may require
| certain privileges in order to make it work.
|
| You can provide a nice higher-level API (like ScreenCaptureKit)
| to access such "privileged" capabilities from normal apps, so
| that arbitrary open-source software (like OBS) can hook into
| it.
|
| It seems like Apple already made ScreenCaptureKit for their
| platforms, and wanted to help OBS by hooking it up to
| ScreenCaptureKit to take advantage of that work.
|
| The alternative, which is to do all the private/privileged
| stuff _directly_ in OBS, means that Apple would have to give
| the general ability for arbitrary software to do what
| ScreenCaptureKit is doing, which may be a security issue
| (spyware that snoops on what 's being displayed on screen comes
| to mind.) Making something like ScreenCaptureKit as the
| supported interface to do this kind of thing, can ensure the
| app triggers the proper permissions dialog/etc so that screen
| recording doesn't happen without user knowledge.
| maxwell86 wrote:
| > Maybe Im being a bit cynical.
|
| If Apple, Intel, AMD, NVIDIA, Arm, Qualcomm, etc. would all
| contribute to open source to make everything work on all their
| devices with good perf, then that would be very good for all
| users.
|
| Expecting AMD to make open source contributions to improve
| software on Apple's hardware or Arm GPUs is "naive", not
| cynical.
|
| It would be like expecting Tesla to go to VW and help them
| improve their combustion engines for free.
| [deleted]
| twelgblerg wrote:
| the_duke wrote:
| Why exactly did you create two new accounts to post the very
| same message?
|
| ( https://news.ycombinator.com/item?id=30113137 )
| ffe2t2tt2t wrote:
| Apple should be ashamed. Microsoft does so much for open source
| (VS code, typescript, .NET, Blazor and dozens other projects) and
| even Goolge does quite a lot. And only $Apple$ is an ego-driven
| company that only cares how to squeeze as much money as possible
| from customers.
| GeekyBear wrote:
| Doesn't Microsoft compile Edge with Apple's open sourced Clang
| compiler?
| viktorcode wrote:
| Apple may have to be ashamed, but bringing up Microsoft as a
| good OSS citizen?
|
| https://medium.com/@keivan/the-day-appget-died-e9a5c96c8b22
| azinman2 wrote:
| I love how this comment is here on a PR from Apple for an open
| source project...
|
| WebKit, LLVM, Swift... these are pretty fundamental open source
| projects, in addition to a bunch of other stuff.
|
| You can't please everyone all the time, and society is too
| addicted to outrage these days.
| veenified wrote:
| If anyone watches "Meet Kevin" youtube channel, you would know
| the bad publicity Apple gets with him attempting to stream on his
| relatively new Mac Pro system. Any effort to improve that
| capability would be in Apple's best interest. Streaming is not
| going away.
| underdeserver wrote:
| https://www.youtube.com/channel/UCUvvj5lwue7PspotMDjk5UA
|
| Seems like a money YouTuber, I've never watched him myself.
| veenified wrote:
| I found one of the timestamped video clips where he hits one
| of the streaming issues on his Mac...
| https://youtu.be/V5SYAHQhEx8?t=260
|
| EDIT: ...and another one...
| https://youtu.be/HBXUy5fZNYU?t=890
| robbrown451 wrote:
| Should this allow OBS to not capture the actual OBS window
| itself? I'd think it would be nice to eliminate that from what is
| captured, for those poor people who only have a single monitor.
| :)
| [deleted]
| yellow_lead wrote:
| It's a bit strange to open a pull request from "Developer-
| Ecosystem-Engineering" instead of an individual account. I wonder
| if every interaction from this account has to be approved by a
| board or something.
| helsinkiandrew wrote:
| From experience in a big company (not Apple) likely direct
| manager then senior manager then legal department. The
| justification and hoop jumping would take much more effort than
| the coding.
|
| Well done to who ever it was.
| saagarjha wrote:
| Contributing to a new open source project requires Senior
| Vice President approval at Apple.
| yellow_lead wrote:
| Jesus
| onion2k wrote:
| Don't Apple have a policy that their developers aren't supposed
| to contribute to Open Source without explicit permission
| (https://news.ycombinator.com/item?id=22935263)? I imagine this
| is the result of that policy - if Apple wants to contribute to
| something _as a business_ there isn 't really anyone who would
| be able to use their individual account to do it without lots
| of people questioning why that person can when others can't.
| dogma1138 wrote:
| Most companies have this policy it's actually quite important
| to protect both the company and the project, it wouldn't
| surprise me if big projects even mandate it on their side
| too.
|
| It usually comes in two flavors - individual contribution as
| you doing something on your own time and equipment and
| official contributions when the company itself contributes to
| a project.
|
| This looks to be the latter rather than the former so it
| would make sense it would come from an Apple account.
| nicoburns wrote:
| > It usually comes in two flavors - individual contribution
| as you doing something on your own time and equipment and
| official contributions when the company itself contributes
| to a project.
|
| My understanding is that Apple's policy is highly unusual
| in that "individual contribution as you doing something on
| your own time and equipment" are pretty much not allowed
| _at all_.
| threeseed wrote:
| > My understanding is that Apple's policy is highly
| unusual in that "individual contribution as you doing
| something on your own time and equipment" are pretty much
| not allowed at all.
|
| I am not sure exactly but I suspect this is employee-
| specific and may be only for those working on sensitive
| projects.
|
| I worked at Apple years ago and it was never in my
| contract or mentioned to me. And there are plenty of more
| recent developers e.g. Holden Karau who were contributing
| to open source projects in their spare time whilst
| working at Apple.
| saagarjha wrote:
| Nope, rather, Apple engineers having side projects is
| employed-specific and usually requires some sort of
| special case for them to let you continue working on your
| thing. This has been a standard part of the contract for
| a while, and it's nothing like a decade or two ago where
| you might have a DTS engineer make a side app or two for
| fun or give their own, unofficial opinions of the SDK on
| their personal blog without approval.
| rcarmo wrote:
| I can confirm that. It was a reason why close
| acquaintances refused to join.
| saagarjha wrote:
| It's more complicated than that. Apple's blanket policy
| towards such contributions is that anything you do in
| your own time needs SVP approval, because it might
| potentially compete with Apple's business interests. And
| as a general policy it likes to deny such requests. Other
| companies have various policies: Google, for example, is
| for the most part "we'll let you do whatever but we own
| the code, and if you want to own it we will make it about
| as difficult as Apple does". The whole "you compete with
| us if you do anything" is a big tech thing, by the way,
| because they work on so many things that they can scare
| their engineers with competition threats on any grounds
| in California. The best that smaller companies can do is
| restrict you from working on the limited thing they work
| on, such as developer tooling or a social network.
| com2kid wrote:
| Meanwhile Microsoft lets their employees do whatever they
| want after hours, so long as no company provided
| resources are used.
|
| I know of developers who made quite a bit of $$$ being
| first out the door with applications utilizing SDKs that
| they wrote. MS is perfectly happy with their own
| developers showing off shiny new features.
| cstejerean wrote:
| Because that's the law in Washington state.
| dlsa wrote:
| And not in california? Its interesting that Apple is seen
| as hip and cool yet operates a tight leash obviously
| because it can, legally. Microsoft is... other things...
| yet is operating a looser leash, albeit also in
| compliance with law.
|
| Interesting but not surprising I guess.
| inglor wrote:
| At Microsoft at least at my site we are encouraged to
| contribute to open source and it even brings
| perks/recognition so really not sure about "most companies"
| here
| rcarmo wrote:
| It's company wide, so yes, Microsoft has a pretty sane
| policy regarding that (as well as clear guidelines for
| dealing with OSS code)
| scarface74 wrote:
| We (FAANG) have a list of open source projects that we are
| not allowed to contribute to without prior permission.
| Anything else is fair game from what I can tell.
| DangerousPie wrote:
| Well, given the amount of publicity this PR is getting it
| probably makes sense to not just let a random software engineer
| post whatever they feel like.
| iSnow wrote:
| Could be related to the decision to remove individual names
| from the product about boxes back when Jobs came back to better
| control leaking of internal information and cut down on
| poaching. I would think that Apple does not want anyone to know
| who is working on the screen capture APIs as this PR would
| probably come from one member of that group
|
| "When Steve came back, one of his company-wide edicts was that
| the names of individuals must be removed from about boxes."
|
| https://bitsplitting.org/2014/01/24/cant-take-that-away/
| SloopJon wrote:
| For those of you who have contributed to a Github (or similar)
| project in your capacity as an employee, do you use a work
| account separate from your own?
| maccard wrote:
| yes.
| saagarjha wrote:
| Depends on the company, usually. Currently, I make my
| contributions with a personal account.
| mr90210 wrote:
| It's a valid point, however shall we at least celebrate a bit
| the fact that a Big Tech is actually contributing in the
| project?
| masklinn wrote:
| TBF I don't know how much "we want $popular project to take
| advantage of our platform" is to be celebrated.
|
| It's better than bitching about bad support without doing
| anything. But at the most fundamental of levels it's really
| the company working for their customers, through a third
| party's project.
| nisegami wrote:
| I think situations where literally all parties involved are
| better off than they were before should be celebrated, even
| if the intentions behind it aren't just philanthropic.
| masklinn wrote:
| So you celebrate every time somebody makes a purchase of
| something they needed and had the means for?
| nisegami wrote:
| If those goods were produced by people paid fair wages
| and using materials sourced sustainably/ethically, sure.
|
| So in practice, not very often
| sokoloff wrote:
| Is a company working for its customers to have a good
| experience with an open source package something we should
| discourage instead?
|
| I'm perfectly happy to celebrate win-win outcomes.
| masklinn wrote:
| > Is a company working for its customers to have a good
| experience with an open source package something we
| should discourage instead?
|
| You are aware that there are more than two options?
| sokoloff wrote:
| Of course. Apple has many options and their choice to
| contribute to OBS allows me many options as to how to
| react; I choose applause.
| q3k wrote:
| I don't know, this feels to me like applauding a car
| driver who uses their turn signals correctly.
|
| "Hooray, you did the thing you're supposed to do. Good
| job you".
| Someone wrote:
| Why would Apple be supposed to do this? Without any other
| argument on the table, taking that statement to its
| logical conclusion, it would imply Apple is supposed to
| help make every single project run well on their
| hardware.
|
| Even when restricting that to "open source projects that
| (cl)aim to run on latest MacOS", I think that's not
| something a vendor is "supposed to do".
|
| So, if Apple only "is supposed to" support some projects,
| what objective criteria should it use to pick them?
|
| I think it's completely fine if Apple wouldn't support
| any open source. I also think it's completely fine if
| developers would choose not to write software for their
| OS because of that.
| yreg wrote:
| Is that rare? I would have thought many FAAG employees
| contribute to open source projects relevant to them as part
| of their work. After all that seems like the easiest way to
| influence the projects.
| jhugo wrote:
| And contributing changes back to an active project is much
| less effort than maintaining a fork in perpetuity.
| swiftcoder wrote:
| There's a pretty big distinction between FAANG employees
| contributing on their own time to things tangentially
| related too their job, and FAANG employees contributing on
| behalf of the company (i.e. being paid to do so as an
| official part of their day job).
|
| Judging by the Engineering account being used to submit
| this patch, this is likely to be an example of the latter.
| yreg wrote:
| _as part of their work_ means during their billed work
| time.
| swiftcoder wrote:
| In that case, no, almost no FAANG employees do that. I
| would have had to file paperwork and receive legal
| signoff for each individual patch to any open-source
| projects that weren't owned by the company.
|
| What does exist is specially "blessed" FAANG teams who
| are cleared to contribute to specific open-source
| projects that are critical to the business. Amazon has a
| team who contributes to the linux kernel for hypervisor
| support, for example.
| londons_explore wrote:
| Facebook.. Yes... Amazon... Yes Apple... Not so much.
| Netflix.. A little Google... Yes...
| viktorcode wrote:
| There's a good post on HN about what it cos Apple to make
| OS X a certified UNIX. Due to the secrecy of the project
| they had to use non-corporate accounts for committing bug
| fixes. The amount of changes was pretty big, but nobody
| excepts the authors can say it came from Apple.
|
| Of course they will commit to open source projects if it
| suits their needs (if they use those projects). But
| people have different opinion on what Apple's needs are.
| pjmlp wrote:
| Amazon...it depends
| oldiphone wrote:
| < The __MAC_10_15 define may not exist on devices running <
| 10.15, resulting in this section not being appropriately avoided
| during compilation. Swapping to 101500 should work for all
| versions of macOS.
|
| So they are mindful of people with old Macs. This is good!
| ripe wrote:
| For others like me who had no idea what "OBS" in the title refers
| to:
|
| It's open-source software for video recording and live streaming.
|
| https://obsproject.com/
| ru552 wrote:
| It's actually some of the best software I've used for
| streaming. Also, the feature to record a browser tab is a life
| saver when I'm double booked and don't want to miss content
| from a meeting.
| mcast wrote:
| Just an FYI you may want to double check the laws in your
| state and company rules on personally recording meetings.
| jcelerier wrote:
| - #if __MAC_OS_X_VERSION_MAX_ALLOWED >= __MAC_10_15 + #if
| __MAC_OS_X_VERSION_MAX_ALLOWED >= 101500 // __MAC_10_15
|
| ah, yes, clean code
| froh42 wrote:
| Interesting thing about "clean code" I just read today:
|
| https://www.steveonstuff.com/2022/01/27/no-such-thing-as-cle...
|
| The article says we need to use more precise words. In this
| case, the macro can create a bug, so is using the macro
| "cleaner"?
| jamessb wrote:
| The message for the PR (under the Conversation tab) justifies
| this as:
|
| > plugins/mac-capture/mac-display-capture.m:621 - The
| __MAC_10_15 define may not exist on devices running < 10.15,
| resulting in this section not being appropriately avoided
| during compilation. Swapping to 101500 should work for all
| versions of macOS.
| masklinn wrote:
| A conditional define might be a good alternative tho?
| jcelerier wrote:
| yes, it's the whole macos compatibility / availability layer
| which is terrible. In contrast a good system like Qt looks
| like #if QT_VERSION > QT_VERSION_CHECK(5,
| 15, 0) ... #endif
|
| and works also for Qt 5.1 or Qt 4 or 3 (i think that's when
| this macro was introduced, pretty much at the same time than
| os x 10.1 ?)
| jakear wrote:
| That's just adding another layer of abstraction over
| exactly what the Mac case does. I prefer code that is so
| simple it doesn't need to be abstract, as every abstraction
| layer is a potential bug layer.
|
| Not even just "potential" in QT's case, a quick search
| turned up https://forum.qt.io/topic/31071/moc-and-
| qt_version_check-bug and
| https://forum.qt.io/topic/37882/qt-4-8-qt_version_check-
| and-... as cases where folks have been bit by some tooling
| in a Qt4 environment not understanding the macro properly.
| cute_boi wrote:
| Windows Version check would disagree with you why this
| abstraction is required. I forgot the api but there is
| kernel api that will contradict with your view points.
| jcelerier wrote:
| > That's just adding another layer of abstraction over
| exactly what the Mac case does. I prefer code that is so
| simple it doesn't need to be abstract, as every
| abstraction layer is a potential bug layer.
|
| I'm happy for you if you never typed 10150 or 01150
| instead of 101500 or whatever but that's definitely not
| my case and I need any tool that the programming language
| provides to help me with that ; version macros are
| unambiguous and I don't remember fucking one up.
| saagarjha wrote:
| In C23 you can type it as 10'15'00 if you'd like.
| jakear wrote:
| Surely you see the contradiction in the system you
| describe as `terrible` being the exact same as the system
| you call `good`? In either case, macros are available in
| modern versions but attempting to use them in old
| versions causes problems (see the links above), so the
| practice is to not use them at all, if you may have to
| target older versions.
| [deleted]
| [deleted]
| vault wrote:
| I hope those changes were planned and agreed upon beforehand. I'd
| hate to review 274 changed files out of the blue
| [deleted]
| artonge wrote:
| Apparently not the first time from the activity of the user:
|
| https://github.com/Developer-Ecosystem-Engineering?tab=overv...
|
| https://github.com/obsproject/obs-browser/pull/310
|
| Strangely, a lot of contributions to numpy.
| ink404 wrote:
| Not too strange if Apple wants a competitive development
| environment.
| viktorcode wrote:
| Maybe I'll be laughed at, but right now I consider the most
| competitive Apple's development environment the Swift
| Playgrounds on iPad.
|
| I just so wish to see this sleek and fast app replacing old
| cranky Xcode on macOS by adding missing features.
| caaqil wrote:
| The pull request page might be more readable:
| https://github.com/obsproject/obs-studio/pull/5875
| jscipione wrote:
| Does this mean I'll finally be able to capture audio in OBS on
| macOS without third party tools like sound flower and blackhole?
| dodgepong wrote:
| This is just for display/window capture, not audio capture.
| whazor wrote:
| Now I hope they improve the situation of virtual cameras. Now you
| need to code sign all kinds of applications in order for them to
| recognize your applications, which often breaks those
| applications.
| evanb wrote:
| I really want to use the virtual camera in FaceTime. But it's
| near-impossible to get it to work.
___________________________________________________________________
(page generated 2022-01-28 23:00 UTC)