Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Comment Re:Umm (Score 2) 331

As the poster had in fact said: >It's NOT just citing sources and peer review...

I don't see anyone saying that in this thread, nor in the summary. Where did you pull that quote from?

As for the central idea I was trying to convey, I said it right at the start of my post: citations and peer reviews are necessary but insufficient. I suppose the shorter version of what I then went on to say is that citations and peer reviews are tools that enable us to build a network of trust, and a network of trust is a tool that can be used to establish the credibility of information, but at the end of the day tools are only useful if people are actually using them, and for that we need to teach critical thinking.

Comment Re:Umm (Score 5, Interesting) 331

They already had this. It's called citing your sources and peer review.

Having read countless research papers that fit your criteria, I can tell you that citing your sources and being peer reviewed are not nearly sufficient. They're necessary steps, to be sure, but I've read more than my fair share of papers from conferences or journals, some even associated with reputable organizations, that were nothing but complete bunk. What you need are citations to trustworthy sources and to be reviewed by trustworthy peers.

And that's the crux of the issue: this is about establishing a network of trust. Citations and peer reviews are an important part of that process, but the notion that they are sufficient in and of themselves misses the point. After all, how is a layperson supposed to know that the American Society for Mechanical Engineers (ASME) is a reputable professional society that has strict ethical and legal obligations, and that the information attributable to it is likely to be trustworthy, but that the American Association for Mechanical Engineers (AAME, which I hope is a fictional entity, but who I apologize to if they actually exist) is a front that's been created by a group to push its own agenda? We see this sort of thing happening all the time in medical, environmental, and other fields that are overshadowed by partisan politics.

Moreover, even if we do manage to establish a network of trust, we still need people to actually trust it in order for it to be useful. How do we do that? By teaching them to think critically and to recognize BS. When they do, they'll naturally gravitate towards trustworthy sources that provide verifiable information. With a world full of people espousing "alternative facts", the very notion of a network of trust can become political, so it's important to train people to pursue the truth even when it doesn't jibe with what they want to believe, otherwise they'll be perfectly content reading peer-reviewed nonsense filled with citations to worthless publications.

It's a shame that fact-based reporting and analysis has become viewed as politically driven, but that's the world we live in. I do agree that citations and peer reviews are necessary, useful tools, but we need to train people to not only use those tools but to also recognize when there's a problem causing them to come up short.

Comment Re:And, I might start buying more from them again. (Score 1) 178

Agreed. As I'd imagine is the case with most people, I didn't know what to get some people for the holidays until closer to Christmas, so I wasn't able to make a single, bulk purchase. As a result, I never had a single cart that was anywhere close to the $49 minimum. It ended up being cheaper to buy individual items directly from the manufacturers than to purchase them a few at a time from Amazon. In the end, Amazon only sold me one item this last Christmas, whereas in prior years I've done the bulk of my shopping on the site.

We stopped using Prime because we were getting less value out of the service than what it cost (YMMV), then our shopping on Amazon dropped off a cliff when they jacked the minimum up to $49. I was beginning to suspect that I'd barely use the site any more, but with the minimum dropping back down again, they may actually attract some of our business again.

Comment Re:News at 11 (Score 1) 65

Previously Gatekeeper had the option to to run apps from "Anywhere", that option has now been removed from GateKeeper settings

The option to run unsigned apps (i.e. apps from "Anywhere") still exists, but rather than being a global setting, it's now handled on a one-off basis by bringing up the contextual menu on any unsigned app and telling it to Open. I think it provides a warning about the risks and then confirms that you want to still open it, but after that it'll run just like any other app, no more warnings or anything. In the last year or two, I've only encountered one unsigned app that required I go through that process, and I'd consider myself a fairly advanced user (as I imagine most other people here would).

Avoiding the MAS is becoming more difficult for Mac users.

In practice, I don't think this is actually the case. Again, I've only encountered one unsigned app in the last year or two. Were that not the case, I might agree, but the vast majority of Mac developers seem to have a certificate at this point, and the second option you listed is the default one, so their apps run with default settings, which means that no one is really being pushed to the MAS. And stories like the ones being described in the summary are becoming increasingly common. Indications seem to point towards MAS usage being in decline for the last few years among advanced users, and novice users are dwindling too as their attention is increasingly drawn towards mobile platforms.

I do agree that macOS is converging on iOS, but I think we're still a good few years away from it becoming that locked down.

Comment Re:News at 11 (Score 2) 65

Lots of things may happen. For now, if the machine is working for you better than anything else you've looked into, keep using it. Simple as that.

As to your concerns, even if Apple decided to do what you said, it wouldn't be an immediate concern. You'd be able to keep using your existing machines for years as people worked on creating/polishing alternatives, given that there'd be nothing forcing you to "upgrade". By the time you needed to purchase an alternative, there'd not only be plenty of them available, there would also be plenty of blogs and other resources providing advice as to which ones suit your specific needs.

All of which is to say, leave tomorrow's concerns for tomorrow. Don't worry about them today.

Comment Re:News at 11 (Score 5, Insightful) 65

To be clear, this is about the Mac App Store (MAS), not the (iOS) App Store. In both cases, you're effectively paying Apple a cut of the profits in order to make your product more accessible to consumers. In the case of the iOS App Store, it's pretty obvious that the 15%/30% cut is worth it, since if your app isn't there, it isn't for sale as far as 99.9% of people are concerned (even though that's not strictly the case).

But the MAS? Its value proposition has always been questionable.

For one, purchasing patterns are drastically different between mobile and PC. Consumers typically already know what Mac apps they plan to buy, rather than browse-shopping like they do on iOS, so whether the app is in the MAS or on a website makes no difference. As such, developers don't lose much from pulling out, or, in many cases, what they lose in unit sales is more than made up in reduced overhead.

Making matters worse for the MAS, it's oftentimes the case that the version of the app sold in the MAS is both more expensive and has less features than the one sold on their website. The MAS has a number of requirements (e.g. strict sandboxing) that make certain features virtually impossible to implement, so the apps in the MAS are oftentimes missing key features found in the direct-sale versions, or they might be lagging behind by a few versions due to the app store review process that all updates need to go through. And because developers don't see much benefit from the MAS, many of them simply tack on a 30% premium for the version sold through the MAS, that way they can recoup the cost. But even in the case that the developer doesn't price it higher, there's no way to offer upgrade pricing for loyal customers, so MAS users end up paying full price for subsequent versions, rather than being able to get a discount that the developer might be offering on direct sales.

All of which is to say, the MAS is a somewhat hostile environment to both developers AND users, so it's not surprising that niche apps aimed power users (i.e. the ones most likely to know how to use a browser to find software) are seeing improved numbers after pulling out of the MAS.

Comment Re:Retarded headline... (Score 1) 55

Absolute gibberish. Start capitalizing only the words that should be capitalized.

Headline capitalization has been a special case in the English language for centuries, so what the editors did here is appropriate, but even if you were to capitalize it normally it would still be "Overeager investors seeking Snap buy Snap Interactive instead", which doesn't do much to help you understand the situation.

Comment Re:Headline doesn't really match actual news (Score 1) 170

I never said Metal was better. Just because I disagree with what I think is a bad argument coming from you, it doesn't mean I'd support the same bad argument coming from someone on the other side. I honestly don't care which "wins" between Metal and Vulkan.

I never said WebGL was unsafe to use. I was confused why you even brought it up, and still am. It's safe to use and it was designed for the web, but it doesn't provide the close-to-the-metal access this new standard is designed to provide, so it's irrelevant to the discussion.

None of the close-to-the-metal APIs (i.e. Metal, Vulkan, and Direct 3D 12) are safe to use with the web as they are now. Additionally, keep in mind that this standard is not just about opening up the graphics layer, it's also about exposing the compute layer. Between that and the fact that none of these APIs provide sandboxing, it should be obvious that they're unsafe.

Just think about it for a sec: if Vulkan or even OpenGL were already safe as they are, why does WebGL only expose a subset of the features they provide? We already have implementations for them, after all, so if they were safe to use, we'd already be using them.

Comment Re:Headline doesn't really match actual news (Score 1) 170

Hi Ash-Fox,

I never implied, nor said, nor would say said that Metal is designed to deal with untrusted code. In fact, I never asserted in any of my posts that Metal was in any way superior in any regard whatsoever to the other, competing APIs, nor would I. I merely criticized some overstated headlines and then some poor arguments that would have been just as poor had they come from a Metal or Direct 3D 12 supporter. They just happened to come from someone supporting Vulkan.

Understandably, I won't be replying to the rest of your comment, since you're making a point that I already agree with.

Comment Re:Headline doesn't really match actual news (Score 1) 170

I'm simply pointing out that Apple don't really care for open standards. If they did they'd implement Vulkan.

As I've already pointed out elsewhere in response to you, you seem to be very confused about what all of this means. You're basically suggesting Apple doesn't care about open standards because they're making a car (a safe abstraction for the graphics/compute layer) instead of implementing a gasoline engine (the unsafe graphics/compute layer). Never mind that they intend to use the gas engine--as well as other engines--in their car.

Comment Re:Headline doesn't really match actual news (Score 1) 170

> For one, Vulkan and its competitors aren't designed for use with untrusted code,


Do you have an _actual example_ that shows this or are you just repeating dogma that everyone else does?

Do you have an _actual example_ that shows there is not an invisible, intangible unicorn standing next to you right now, or are you just repeating dogma that everyone else does?

Repeat after me: you can't prove nonexistence, which is why the onus is on the side claiming existence. If you want to claim that they designed it that way, the onus is on you to prove it. Have fun.

Moreover, what does the cross-platform capabilities of WebGL have to do with my statements regarding Vulkan? Yes, WebGL is cross-platform. What of it? Apple's proposed standard may compete with or attempt to displace WebGL, but both of those are built on top of underlying technologies like OpenGL, Vulkan, and Metal, and between Vulkan, Metal, and Direct 3D 12, none are widely available across a multitude of platforms yet.

Comment Re:Vulkan (Score 1) 170

But then how can Apple gain a proprietary stranglehold on the industry? How can they force adoption of their own standard

Yeah, it's a real shame how they used their stranglehold over WebKit to control the direction Chrome is going; LLVM and related technologies (e.g. Clang) to control the direction a huge chunk of the software industry is going; CUPS to control the printer industry...

A real shame.

Not to mention all of the other projects and code they contribute to the open source community.

I agree that Apple does do a lot of proprietary stuff (e.g. connectors, protocols, etc.), but they're used as a means for tying people to their hardware (i.e. where they make about 90% of their money), rather than as a means for extending their reach to other platforms. When Apple engages in community-driven projects like this, it tends to be for one reason alone: their interests align with the community's, so they stand to gain from involving the community. That's it, plain and simple, and their track record backs that up. It's when they don't involve the community, that we tend to see the sort of stuff you're talking about (e.g. MPEG).

The only other valid explanation for what they're doing is that they perceive a competing graphics API as providing a competitive advantage to someone else (e.g. maybe they think Microsoft can leverage Direct 3D 12 in Edge?), so they're willing to commoditize web graphics, including their own, in order to negate that advantage. But even if that were true, we still benefit.

Comment Re:Vulkan (Score 4, Informative) 170

Everyone in the comments suggesting we should just use their favorite graphics API is missing the point entirely.

Neither Vulkan nor its competitors are safe to use with untrusted code from the web. Allowing any random web developer to have access to the full capabilities of any of those APIs is a recipe for disaster. This standard is, from what I can gather, intended to be a layer that abstracts away the underlying API, whether it be Metal, Vulkan, or Direct 3D 12, which should provide a safe means for using them.

For an initial implementation, Apple is providing a prototype that is compatible with Metal, given that they had apparently already done quite a bit of work mapping Metal to Javascript, but it's clear that the end goal with this standard is to provide something that is compatible with all of these close-to-the-metal APIs. I imagine that version 1 of the standard will resemble an intersection of features between the competing APIs, that way they can ensure the broadest compatibility right from the get-go.

In addition to but separate from the web standard, they're talking about taking Metal cross-platform. That wouldn't affect the web standard (which, again, should be able to work on top of any of these competing APIs), but it would ensure that the standard is usable on any platform they choose to support with Metal. If they do take Metal cross-platform, that would seem to suggest an uptick in their interest in creating web-based products that are consistent and in top-shape across a variety of platforms, in much the same way that Google created Chrome to do the same.

Comment Re:Headline doesn't really match actual news (Score 4, Informative) 170

You clearly have no idea what any of this is about, because what you just said is a terrible idea regardless of whether you support Vulkan or not.

For one, Vulkan and its competitors aren't designed for use with untrusted code, so there are quite a number of significant security and technical concerns with your notion that we can simply adopt one of them as a web standard that any random web developer has full access to (which would've been just as true had you said Metal or Direct 3D 12 instead). What you "need", then, is a safe layer that abstracts the underlying API and provides safety to the user (I say "need" in quotes, because I'm not actually clear that this is something we want, let alone need).

Second, neither Vulkan nor its competitors are actually cross-platform in practice today. It may be the case that one of them will become more widespread over time, but, for now, the world we live in is a fragmented one. Any given platform likely supports at least one of these competing standards, but you can't count on having support for any particular one. A web standard that lives over all of them would make it possible to tap into that power without having to know anything about any of them.

When they talk about using Metal for this standard's initial implementation, what they mean is that they've already done most of the work of mapping Metal back to existing web standards (e.g. Javascript), so they have a head start on which features a standard may be able to support and what that web API may look like. They'll likely take something resembling the intersection of Metal's features with Direct 3D 12's and Vulkan's features so as to provide an initial release of the standard that works across most platforms.

When they talk about Metal going cross-platform, that's a separate (but related) topic. It wouldn't affect this standard (i.e. you should eventually be able to use this standard with Metal as easily as with Vulkan), but it would provide them with a means for ensuring the availability of the standard across any platforms supported by Metal.

Comment Headline doesn't really match actual news (Score 4, Informative) 170

Where in the article does it suggest that Apple is making a power play here to position Metal like the headline says? This really doesn't have a whole lot to do with Metal specifically, and is instead about leveraging the entire class of APIs that have been coming out that are closer to the (lowercase) metal. In fact, they specifically said so in the summary:

As noted by Dean Jackson from the WebKit team, advancements in the GPU hardware space has led to identical enhancements in software APIs. He cites platform technologies like Apple's Metal, Microsoft's Direct3D 12 and the Khronos Group's Vulkan as offering lower overhead, and thus better performance, than the OpenGL standard.

The only thing special about Metal that's mentioned in the article is its role in the initial implementation. To pull the relevant quote:

While Metal appears to underpin Apple's initial web graphics proposal, the company does not expect its concept to become the ultimate standard. That said, it appears Apple is angling to take Metal cross-platform.

"We don't expect this to become the actual API that ends up in the standard, and maybe not even the one that the Community Group decides to start with, but we think there is a lot of value in working code," Jackson says.

So, basically, Apple folks have access to Metal and understand how it works, so they're starting with what they know and have so that they can get the ball rolling quickly. Where it goes from there is up to the community, which, given Apple's typical approach their open source/community-driven projects (e.g. WebKit, LLVM, Clang, Swift, etc.), it's likely that they actually mean that. Of course, they'll no doubt use their role in the community to try and steer things to their own advantage, but if they do so too much it's likely that this will simply become another dead-end "standard" that no one adopts.

Slashdot Top Deals

Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec