Re: [dev] Collecting sins of Apple
Martin Kühne wrote: > TL;DR, while I'm sure most of this stuff holds further scrutiny, I just doubt > it's generally a good idea to list so many problems while providing no > technical context whatsoever. Heyho Martin, I didn't want to do the whole schoolwork for Lukáš, so I just gave a hint/possible fact which he should be able to check himself. It's important to learn how to research arguments to build your own oppinion. Providing Lukáš with ready-to-use text blocks would just increase the filter-bubble problem. I think other responses had similar intentions. --Markus
Re: [dev] Collecting sins of Apple
On Sun, Oct 23, 2016 at 12:19 PM, Markus Teich wrote: > Martin Kühne wrote: >> TL;DR, while I'm sure most of this stuff holds further scrutiny, I just doubt >> it's generally a good idea to list so many problems while providing no >> technical context whatsoever. > > Heyho Martin, > > I didn't want to do the whole schoolwork for Lukáš, so I just gave a > hint/possible fact which he should be able to check himself. It's important to > learn how to research arguments to build your own oppinion. Providing Lukáš > with > ready-to-use text blocks would just increase the filter-bubble problem. I > think > other responses had similar intentions. > > --Markus > So, OP, take note and don't leak our laziness into your final product. I chimed in because I totally missed any mention of OP's responsibility here. The problem is that I feel like copy+paste can really misrepresent the open source community as a whole. The few of us content with researching a subject poorly with little to no aspiration to technical detail and accuracy may cause real harm to the many of us who take a lot of care about these things. So it does you and us a favor to look at issues with care. Which means, you are left with pointers into a few directions really worth looking into more closely, and as I'm not in depth educated about thing I wouldn't buy myself, I'd be actually interested in your findings. cheers! mar77i
Re: [dev] Collecting sins of Apple
Hello, thank you for all your great answers. They are greatly appreciated and help a lot. >This thread is, as I somewhat expected, a total train wreck. > >Replying with regard to technical criticism regarding osx, because >literally *none* of the claims could be substancially supported by >even anyone else's analysis or facts. So most of what I read about >apple technically, I'm referring to the osx criticisms listed, were >obviously more FUD than anything else. > >TL;DR, while I'm sure most of this stuff holds further scrutiny, I >just doubt it's generally a good idea to list so many problems while >providing no technical context whatsoever. The thread turned out how I planned. A lot of information and sources, from which I will filter out things I already know and are included in my work already and get rid of the FUD. Then I will take the facts that are usable for my work and are new to me and look up more information to get some context for them and ensure their factual correctness. Indeed it would not be a good idea to list many problems without any context, but that's of course not what am I going to do in my speech. >So, OP, take note and don't leak our laziness into your final product. >I chimed in because I totally missed any mention of OP's >responsibility here. The problem is that I feel like copy+paste can >really misrepresent the open source community as a whole. The few of >us content with researching a subject poorly with little to no >aspiration to technical detail and accuracy may cause real harm to the >many of us who take a lot of care about these things. So it does you >and us a favor to look at issues with care. Yes, you are right that copy+paste can really misrepresent the whole open source community. We all know how misrepresentation can be bad if we look at how the media et al. mangled the meaning of the words "hacker", "hacks" and "hacking". Of course, I am going to research the subject a bit more in-depth, so that I don't end up like CNN with Mr. 4Chan. Especially since I am sure that those of the crowd that will be listening to me will not hesitate to fact-check what I say in order to disprove my speech, therefore it is my responsibility to make sure everything I present is correct. >Which means, you are left with pointers into a few directions really >worth looking into more closely, The pointers are exactly what is useful for me and I will indeed look into them closely. >worth looking into more closely, and as I'm not in depth educated >about thing I wouldn't buy myself, I'd be actually interested in your >findings. Yes, I plan to post the results and reception of my speech here afterwards for everyone to see. regards, Lukáš 2016-10-23 15:10 GMT+02:00 Martin Kühne : > On Sun, Oct 23, 2016 at 12:19 PM, Markus Teich > wrote: >> Martin Kühne wrote: >>> TL;DR, while I'm sure most of this stuff holds further scrutiny, I just >>> doubt >>> it's generally a good idea to list so many problems while providing no >>> technical context whatsoever. >> >> Heyho Martin, >> >> I didn't want to do the whole schoolwork for Lukáš, so I just gave a >> hint/possible fact which he should be able to check himself. It's important >> to >> learn how to research arguments to build your own oppinion. Providing Lukáš >> with >> ready-to-use text blocks would just increase the filter-bubble problem. I >> think >> other responses had similar intentions. >> >> --Markus >> > > > So, OP, take note and don't leak our laziness into your final product. > I chimed in because I totally missed any mention of OP's > responsibility here. The problem is that I feel like copy+paste can > really misrepresent the open source community as a whole. The few of > us content with researching a subject poorly with little to no > aspiration to technical detail and accuracy may cause real harm to the > many of us who take a lot of care about these things. So it does you > and us a favor to look at issues with care. > > Which means, you are left with pointers into a few directions really > worth looking into more closely, and as I'm not in depth educated > about thing I wouldn't buy myself, I'd be actually interested in your > findings. > > cheers! > mar77i >
[dev] [stali] Root CA certificates
Hello, what is the recommended way to obtain a decent bundle of CA certificates for stali? Like the ones I find in /etc/ssl/certs in my current distro. Thanks Bruno
Re: [dev] [stali] Boot time (was: The stali way to wifi)
> On 10/21/16 11:48, Anselm R Garbe wrote: > > I've been arguing against MS Windows' misdesign to reboot the system > > on configuration changes. But from a stali perspective I kind of > > prefer rebooting the system for the prize of avoiding a daemon or > > runlevel management. It's simpler and it also makes you "configuring" > > a system less. > > > > "Configuring" is always an indicator of suckiness. If you're that worried about speed though (and you don't seem to be) or just want to skip crappy firmware, you could try to kexec, since you'll probably disagree with the reference implementation build system at least. But I suppose that that's a very low priority now, right? On Fri, Oct 21, 2016 at 12:19:52PM +0200, Paul Menzel wrote: > I totally agree. Same goes for suspend to RAM in my opinion. They're not comparable when you've got quite a bit of work going on. There are likely enough “edge cases” to that thinking. And besides, how hard is it to just echo mem to /sys/power/state? Who said suckless use cases need userspace support? I'd leave that in the kernel at least, because it's not an unlikely use case, though I already build my own kernels with lots of the junk stripped anyway… If all I want to do is flip my laptop closed to go from the kitchen to the bedroom…
Re: [dev] [stali] Root CA certificates
On Sun, Oct 23, 2016 at 8:47 AM, Bruno Vetter wrote: > what is the recommended way to obtain a decent bundle of CA certificates for > stali? Like the ones I find in /etc/ssl/certs in my current distro. I suggest just grabbing cert.pem from libressl.
Re: [dev] [stali] Root CA certificates
> I suggest just grabbing cert.pem from libressl. Thanks for the quick reply. Do you know if there is a designated default path for certs in stali? >From what I see, stali's curl is not built with any certs default path or >default bundle file. I don't know if it falls back to some libressl settings >in that case (I have no openssl.cnf yet). Same question for other applications >using certs like git. I just want to understand how it's meant to work. Bruno
Re: [dev] Collecting sins of Apple
While this can seem relatively unimportant to some, the use of proprietary screws (Pentalobe) really does sum up Apple's stance toward its client base.
Re: [dev] [stali] Boot time (was: The stali way to wifi)
> If all I want to do is flip my laptop closed to go from the kitchen to the bedroom… then your laptop should realize you're doing nothing and keep the CPU in idle state anyway. you shouldn't need to tell it specifically, especially for such a short time. shouldn't be worth it. sane laptops will switch off the light when the lid is closed without software intervention. for longer periods, like a whole night, or going outside somewhere i obviously regularly put my laptop to standby. and indeed echo mem to /sys/power/state is enough for this. the problem is that this requires special software support in all kinds of drivers, which indicates that the hardware got designed in a silly way. but commonly you either have to use some stupid "workaround" in the driver or you are left with completely ignoring the existence of this "standby" feature. On 10/23/16, a...@alexpilon.ca wrote: >> On 10/21/16 11:48, Anselm R Garbe wrote: >> > I've been arguing against MS Windows' misdesign to reboot the system >> > on configuration changes. But from a stali perspective I kind of >> > prefer rebooting the system for the prize of avoiding a daemon or >> > runlevel management. It's simpler and it also makes you "configuring" >> > a system less. >> > >> > "Configuring" is always an indicator of suckiness. > > If you're that worried about speed though (and you don't seem to be) or > just want to skip crappy firmware, you could try to kexec, since you'll > probably disagree with the reference implementation build system at > least. But I suppose that that's a very low priority now, right? > > On Fri, Oct 21, 2016 at 12:19:52PM +0200, Paul Menzel wrote: >> I totally agree. Same goes for suspend to RAM in my opinion. > > They're not comparable when you've got quite a bit of work going on. > There are likely enough “edge cases” to that thinking. And besides, how > hard is it to just echo mem to /sys/power/state? Who said suckless use > cases need userspace support? I'd leave that in the kernel at least, > because it's not an unlikely use case, though I already build my own > kernels with lots of the junk stripped anyway… > > If all I want to do is flip my laptop closed to go from the kitchen to > the bedroom… > >
Re: [dev] [stali] Root CA certificates
On 10/23/16, Bruno Vetter wrote: >> I suggest just grabbing cert.pem from libressl. > > Thanks for the quick reply. Do you know if there is a designated default > path for certs in stali? It looks like the stali curl_config.h sets CURL_CA_BUNDLE to /etc/ssl/certs/ca-certificates.crt[0]. I suspect that this is the detected location for the cert bundle on the system used to run curl's configure script. > From what I see, stali's curl is not built with any certs default path or > default bundle file. See above. > I don't know if it falls back to some libressl settings > in that case (I have no openssl.cnf yet). Same question for other > applications using certs like git. I believe git uses libcurl, so probably just uses the path specified in curl. It looks like the default path in libressl is to use OPENSSLDIR "/cert.pem", and stali is using the default value of OPENSSLDIR, /etc/ssl. So, other applications that use libressl directly and have no default are probably looking for it in /etc/ssl/cert.pem. > I just want to understand how it's meant to work. I don't know how it's meant to work on stali, but on my system, I install cert.pem to /share/libressl/cert.pem, and create a symlink /etc/ssl/cert.pem -> ../share/libressl/cert.pem, and set CURL_CA_BUNDLE to /etc/ssl/cert.pem.
Re: [dev] Collecting sins of Apple
On Fri, 21 Oct 2016 21:54:04 +0200 lukáš Hozda wrote: Hello Lukáš, > Do you know about some bad things Apple has done in their pursuit of > ever-increasing profits? Do you know about ways Apple is against free > and open-source software? Please let me know. Naturally, if you know > about some good deeds of Apple, I accept them as well. Apple used to make very good hardware, and I am running Mac minis here as work computers and servers, and some of them have been serving me for almost a decade now. But these machines were built by an older alter ego of Apple, and it has been almost 4 years since I've last bought a Mac mini. At suckless.org we are releasing our software under permissive licenses like MIT and ISC, so in general I'd love to see suckless software running in macOS and everyone who writes suckless software has to accept the fact that his software can end up there. They already made the switch to LibreSSL, so one can say that they are interested in using quality open source software. Liberty wise it may not be very good, but when you count up the numbers, the macOS userbase might be the biggest percentage of all users of LibreSSL. When you're discussing Apple, you always need to compare the pre- to the post-Jobs era. Job's vision was to build up an ecosystem that consisted of hardware and software. What really catches this spirit is the following quote by Alan Kay "People who are really serious about software should make their own hardware." And this approach works: Macs are reliable and used to be very reliable machines, as already pointed out in this thread IBM found that out as well a while ago. Now, the post-Jobs Apple has changed in many respects, and they've made decisions excluding the professional market further and further. Aiming your product at the consumers works of course, and the bean counter Tim Cook sees this as the only logical decision (consumers are our biggest market group, so it should be our target group). The problem this really brings is the fact that the highly-invested developers the Apple ecosystem needs are depending on "professional" Mac machines to work with, and there are only so many things even an Apple fanatic can put up with. If this trend continues, more and more "high-end" developers will leave this area and move towards developing for other platforms. What is keeping them back is the fact that the App Store is by far the most profitable of all app stores, but this gap is closing with more and more developers flooding the market. I don't think it will be doomsday for Apple in the coming years, and they are doing really well. But all the money in the world can't buy you a developer-base that is loyal and invested in developing good applications for your ecosystem. This might all end up in a big pile of uselessness. I'm looking forward to what they will announce on Thursday at their Mac event[0], but won't hold my breath. With best regards Laslo [0]: http://www.apple.com/apple-events/october-2016/ -- Laslo Hunhold
Re: [dev] Collecting sins of Apple
Btw, Laslo's post reminded me that I in fact posted this article about the topic on my feed. cheers! mar77i [0] https://medium.com/chris-messina/silicon-valley-is-all-wrong-about-the-airpods-8204ede08f0f#.9ro6pge1w
