Apple Developer Center still down
marco.org
marco.org
If you've ever poked around with the way that Apple's website works, you can see that the entire place is a huge mess. There's old servers running ancient (pre-2004) perl scripts alongside the brand new iCloud gear. I can't imagine how the authentication for AppleID is working as login details still work on the ancient pages (think pinstripes and glassy buttons). Depending what URL you hit, the webserver is using php3, php4, perl, python or maybe WebObjects (java).
At one point I wrote a scraper that was targeting one of their product pages, and kept getting random, unexplainable results. It turned out that one of their product areas was behind a round-robin load balancer, with three completely different apache versions on each server. The page was dying on one but not the other two. In the end I just had to repetitively scrape until I hit a good response.
Even the domain for the "maintenance" page for the developer section is telling. It's just a broken template system regurgitating a bit of the homepage.
http://devimages.apple.com/maintenance/
Truly a hacked together system. Some engineers at Apple must be having a truly awful weekend, no matter the cause and solution.
There's a lot more weird around apple.com if you go looking. I'd love to hear the story behind their MX/SMTP hostnames (thousands of them) getting called "badger" and "msbadger".
I haven't used SSI before, but after researching various technologies, it looks like a solution for my own caching use-case, and I am planning on implementing it. I realize that it's a rather old technology, but as long as there's nothing wrong with it, I think it could work for me.
Is there something wrong with it? The only thing that I have seen is that the "exec" command is dangerous, but NGINX doesn't seem to implement it.
Let's imagine that the code in question was not SSI, but instead PHP. You might have this running behind a copy of Apache and mod_php. Your website includes both code and images.
This website runs like this, but maybe the way you configured Apache is too slow to handle downloading all the images: these large-file static assets need to be handled by a different system.
So, you install a copy of nginx and point it at the same folder. You give this copy of nginx a new hostname, such as "devimages.example.com" as opposed to the Apache "www.example.com".
Problem solved, right? No. Now if you go to http://devimages.example.com/index.php you get access to the source code to the website (which is generally considered a big security failure).
That seems to be what's happening here: the "devimages." hostname is configured to bypass the SSI parser, and you are getting to see how the page is composited. This could be a problem.
However, it also might not be a problem: it largely depends, which is why I was just idly speculating; it certainly feels wrong, though. As for SSI? I was serious: I love SSI, all my stuff uses it.
The Reseller Store has been down the whole time the Developer Center has been down. Even more interesting perhaps, our company's "master apple id", which is used to place multi 100K USD orders from Apple, got some strange seemingly manual password reset from Apple about the same time as the Developer Portal went down.
Apple's hardware service portal (http://gsx.apple.com) has also been even more flakey this week than normal.
Something is broken over at Apple.
The difference now is that "prosumer" application developers have enough economic weight to register as a force, but not enough to cause Apple to reconsider their entrenched developer relations.
I have nothing to do with Apple anymore so I can't check it myself :)
Do we read this, you have an AAPL short order in tomorrow's market open?
I find no financial news on this.
I find the explanation of massive, unrecoverable data loss plausible, and your insinuation inane.
From Feb this year:
"Earlier today it was reported that Apple’s computers had been compromised by a zero-day exploit in Java. Apple quickly released an update to patch the flaw for all Macs, but not before some of its own employees had been hacked.... A site called iPhoneDevSDK has been revealed as the means by which a dangerous exploit was injected via a Java plugin."
http://www.cultofmac.com/216618/this-iphone-developer-forum-...
I hope that what ever it is, it doesn't put too big a crimp in them.
http://www.clingmarks.com/apple-please-be-serious-about-itc/... http://www.clingmarks.com/ios-vs-android-mobile-dev-platform...
Like desktop use, for one. People will not adopt Linux for their desktop/laptop even when offered for free. Where by people I mean more than 1% of them.
If you'd install OSX or Windows on a non techie who grew up using just Linux, I'd think the retention rates would be much lower.
(And because it always seems to be necessary to add this disclaimer: I've been using Linux fulltime for over a decade; I'm not a critic, just a realist.)
It also says, given the chance to be the default desktop, Linux can have higher than 1% market share.
Only every attempt to sell hardware that ships with Linux (by several companies) failed.
And the "switch to something different" didn't seem to bother those going to OS X.
OS X, in less time than what Desktop Linux was promoted (1998-2013 for Dektop Linux, 2001-2013 for OS X), and with more expessive hardware, went from 2% to around 12% in the US (and even more for laptop share).
>In my experience Linux usage has about 50% retention rate among those I installed the OS for.
Selection bias.
As an aggregate measure, spread across several million people? Perhaps. Resolving that is just a matter of looking up the data.
But that's not the question that matters for an actual developer. What actually matters is: How much money are you making on one platform, and how much could you make on the other? That question has a lot more to do with whether or not a developer makes his or her rent next month than the aggregate measure above.
I'm not saying it's useless to look at the long-term picture. I'm just trying to show that it's a big mistake to focus on that to the exclusion of more pressing things first.
Now it's true that this isn't quite apples to apples since Linux is more fungible than iOS in most regards, mostly thanks to it's open source nature. For example moving your web application from Linux to FreeBSD is likely to make less of a revenue difference than say moving from iOS to Windows Phone 8.
The biggest point is probably that the existence of an Open Source/Free operating system has probably enabled more profitable businesses to exist than iOS.
Maybe.
On the one hand, I know exactly how great it is to have development tools that are a free download away (I remember shelling out hundreds on a C++ compiler in the mid-90s). Open source definitely rocks in this respect.
On the other hand, I know that without the iPhone, iOS, and all of the associated things that came with it (including the industry's massive pivot to compete in its wake), things might look very different for an app developer today. (Or at the very least they'd be slower in getting to this point.) I think it's important to realize that there were no independent app developers in 2007 - writing, buying and using software for the Palm handhelds or Windows CE was radically different on nearly every level.
I would still wager that more paid developer hours go towards stuff that ends up being executed on top of Linux than iOS though.
You're not writing a PHP application for Linux, you're just writing a PHP application, which can run on one of Linux, Windows, OSX, etc. Just because you choose to run in on Linux does not mean you wrote it specifically to be run on Linux, nor should it be included in the metric for Linux apps.
Rarely.
As I said before, you're not developing for Linux when you make a web application. You're developing for Rails/PHP/whathaveyou. These are all OS-agnostic and can be run on any OS. I can run my PHP app on my Macbook, my Linux server, or my friend's Windows desktop. They all work. Because it's not meant to be built for a particular OS.
I don't understand how you can be this stubborn about it. If the language can be run on any number of platforms, then, by definition, it's not an application for one specific platform.
I don't think it's invalid to describe a web app deployed to Linux or an embedded system running Linux as a "Linux app" but I guess that is really semantics.
Unless of course you're talking about building a single Linux virtual machine image and deploying it to thousands of servers. That actually works phenomenally. Doesn't work as well with Apple's software. Or Microsoft's for that matter (though this is largely a question of licensing cost.)
Without a doubt. IBM, Google, Amazon, and many, many others are deep in the Linux eco-system. Pretty much all supercomputing is done on Linux, and all the boring cloud/infrastructure/scientific stuff is done on Linux.
Yeah, one has to admit that Mac users are a more receptive audience for the high-brow humor of sophisticated fart apps.
Also, we're hiring: http://aws.amazon.com/sdejobs/
Yes, the whole world "uses Linux" in one way or another. But Linux is not a viable consumer platform (No, Android doesn't count).
https://www.neflix.com https://www.amazon.com
And we're not the only people making consumer-oriented Linux software. For example, https://gmail.com .
I realize this might not be what you're saying, so I'll slay a misinterpretation for those that might hold it: going only by the sheer number of users on a platform alone does not mean that it is going to be a good idea for you to develop for it.
Most notable point is that iOS users spend more than 3x on apps than android users. Also, the same exact app on the iTunes Store tends to make more then 3x in sales than the same app on Google Play.
I'm not justifying Apple's ever increasing shift towards enacting strict constraints on their platform developers, but the comparison with Linux is pointless.
Any specifics, or are you just trolling?
The company I work for develops high-end desktop software for Linux, Mac and Windows, and Linux generally causes us the least trouble and OS X (thanks mostly to atrocious graphics drivers and OpenGL support in addition to really bad memory allocation/paging issues that have only just been fixed in Mountain Lion) the most trouble. And this is on limited numbers of hardware and software variations for OS X.
But we've got customers running everything from RHEL 4.5 to the latest and greatest Ubuntus, Mints and Arch.
All with the same binary installers.
The only linux-related weirdness I can recall in the last two years distro-wise was Scientific Linux, which seemed to have some weird XOrg config issues.
So you integrate with the user's desktop environment, using standard local widgets, theming, integration with UX guidelines, local library dependencies, etc?
Or are you shipping a Qt app with your own dependencies included? If so, Qt is pretty notoriously buggy on OS X (and rightfully disliked by most users as it stands outside all platform conventions), perhaps explaining some of your complaints.
I don't believe there are general UX guidelines for Linuxes, but for things like notification popups, system tray stuff, yeah, we do all that natively to the distro through Qt (DBus handles all that transparently within Qt very nicely).
We ship Qt as shared libs with the binaries and all dependencies we need system-wise statically - i.e. zlib, libpng, libjpeg are statically linked. For things like embedded Python, we have to do the same on OS X anyway, due to different python and zlib versions per OS X version.
As for Qt and OS X regarding nativeness - I keep hearing this, but I never see any good examples. I agree it's possible to create Qt Apps on OS X that looks crap, but it's also possible to make them look native as far as I'm concerned. The only thing I can remember not being able to easily do in Qt regarding OS X widgets is the horizontal grouping of side-by-side buttons in radio-button fashion. But it's easy enough to knock up a QWidget subclass which replicates this. But admittedly I don't think I've tried to replicate every possible OS X control/widget...
I think what might be the most difficult part of making a Qt app on OS X look native is the layout and spacing stuff, which generally does seem to be a bit crap within Qt on OS X.
I can have the same code to do a side-panel with edit values in a panel, and it looks great on Linux and Windows: http://imgur.com/kUI90ry
on OS X: http://imgur.com/yqigBdw
and the spacing and padding is all over the place - so I have to add a manual style-sheet to get the padding and spacing right, which is crap (image above is without extra stylesheet). So I'm not saying it's perfect or easy, but I think it is possible.
on 10.6 (and 10.7), memory allocation/paging is pretty atrocious if you haven't got much free mem left.
Basically, OS X prioritises paging to disk over freeing up Inactive memory (which isn't actually being used for anything at present), which is pretty crap. So it's very easy to make it page when it shouldn't when you allocate loads of memory, and the system will generally just grind to a halt.
Apple fixed this in 10.8, so now it will free up Inactive memory first, before it starts paging.
But neither of these explain any crashes within Nuke.
Does QT basically render a bitmap, or does it use the native controls and just has some odd default styling? If it's the first, then I would probably do the UI in native Objective C/Cocoa and keep a nice cross platform base for the VFX core of the app. Not sure if that's feasible for your application of course.
http://imgur.com/68b9eoO - is native Cocoa moc-up in XCode.
I concede the borders are slightly different, but I personally wouldn't have noticed or minded.
The render button is a custom button - the only difference from the native one is the right-hand menu triangle which isn't native.
Qt has styles, and draws controls itself via vector drawing. And you can customise this yourself: So you've got all the power in the world to do what you want, but at the expense of loads of complexity that no-one's really going to go to the trouble of doing. So basically, it tries to emulate the controls on all platforms, and does a pretty poor job on OS X.
I would side with the reader below, I think that going for a completely different look works better than 'almost' native. Ableton Live is a good example I think that has (almost) the same UI on Mac as on Windows which doesn't look bad on either OS.
I am thinking of Pixelmator, or Apple's Final Cut Pro and Motion for comparison to your screenshot. Even modern versions of Photoshop manage to look much nicer than that.
Qt "emulates" native control appearances by drawing them itself. This means it doesn't get it 100% correct (in OS X's case). You can apply stylesheets to configure all aspects of spacing and appearance, so in theory it's possible to write a stylesheet to completely emulate OS X's controls (or at least the majority of them), but that'd be a lot of work which you probably wouldn't want to do.
I could make it any colour I wanted with stylesheets in Qt - this was a personal app, and I'm not too concerned with what it looks like.
Google may develop a lot of things behind closed doors but let's give them credit where credit's due.
No wonder you're having issues on OS X.
There are many software categories where visual-design decisions are not the only competition advantage.
Different UI toolkits make doing certain things hard, certain things easy, and some things damn near impossible without large effort on the part of the developer.
So when the parent commenter says "Nobody on OS X wants a Qt app", I'd argue that yes, although you can make a "well designed QT app", it's much harder to make a "well designed OS X app" with QT.
Why will it be less likely to be a well designed OS X app? Because it will be different to a Cocoa app made with interface builder, in subtle and sometimes not so subtle ways. Sure you can code around these and make adjustments, but the level of effort and investment to get to the stage of if you'd just built it with a more suited tool for the job (Cocoa / Interface Builder on OS X) is quite high.
This is why there is some truth the the admittedly generalised statement made above that "Nobody on OS X wants a Qt app".
There aren't any competitors, however, so people use Mathematica.
I use high-end expensive that are Qt-only too, but I would gladly switch if there were other options, because Qt is buggy, uses non-intuitive non-standard UI, exhibits poor performance due to impedance mismatches between the Mac and Qt event/threading models, and ultimately decreases overall utility of the UX.
This may well be true, but it's quite possible it's just the developer was lazy and didn't do all the effort to make it look native.
Edit: in fact, I'll give an example: VirtualBox - it does look crap on OS X, but that's because the developers obviously didn't make any effort to make it look native. They've got icons in tabs pane buttons and huge toolbar buttons along the top (which isn't a unified toolbar btw - which would make it look more native), which goes completely against the way OS X apps tend to look.
I've literally never been fooled by a Qt app -- a Mac user can spot that hot mess from a mile away. It's not just a matter of visual layout and UX, although that matters and always falls somewhere between subtly or completely wrong.
The controls also tend to lag at weird times, behave slightly strangely, demonstrate unusual font metrics, etc. The apps tend to exhibit bugs related to menu bar event handling, window management, on and on, and crash more than any other apps I use daily.
This isn't a huge surprise given that Cocoa is designed to be the first and only gatekeeper between events, the OS, UI controls, and Cocoa's main event loop, and most of what makes Mac apps a Mac app has to do with the APIs and integration that you lose first-class access to once you deploy Qt -- that includes 'simple' things like UI layout metrics, which Qt has to re-implement.
I abandoned almost all those Qt apps on my list above. I even dropped EAGLE, despite being "native", in favor of Altera on Windows, which I paid a hefty premium for in no small part because it wasn't a pile of broken UX, Windows or not.
I still use IDA Pro, but the minute http://www.hopperapp.com/ can replace my IDA Pro usage, I'll switch in a heartbeat.
Although having looked at hopper, I must say I'm not convinced it seems any more native than a Qt app on OS X could look if work was concentrated with this goal in mind. So as I said in my VirtualBox comment, I think that while indeed it is a Qt deficiency that apps don't look native straight from the compiler, more work could be done by the developer to make it more native-like.
I've seen controls acting weirdly but only QPushButtons - that seems to be regarding the hit-test area - we've had to sub-class a lot of them on OS X to fix this by making the hit test area bigger which is annoying. There's also a pretty bad spacing/padding/layout issue as I alluded to in another comment.
I agree with the event stuff as well - definitely one of the biggest things which affects us is that sometimes mouse/keyboard events don't get sent to the app if the app isn't active or the mouse isn't over a particular window. Debugging through Qt, it seems that Qt never gets the event from the OS, so we have to install event filters for all windows and intercept them which is crap. We've also seen weird stuff like key release events being received before key down events - again debugging through Qt, it looks like an OS X issue in that that's the order they come in from the OS, but again, without a native version to compare to, it's difficult to tell or test.
Generally the crashing of our apps is due to graphics drivers or memory allocation issues (we deal with huge amounts of memory), and I'm not aware of Qt itself being the result of any crashes on OS X for our apps any more than other platforms, but I guess without a native version to compare to, it's difficult to say - but Qt is very rarely the cause of crashes in my experience and I generally develop for Linux and OS X.
It's heavily Qt-based, and doesn't really follow any Apple design guidelines. But it's the best 3D texture painting app in the world for high-end work.
And if you're really concerned, you can just use the JVM.
> It'd be nearly impossible to write Linux software, or download Linux development tools, or generate a Linux binary that a device was allowed to run. It'd be awful.
You clearly don't understand how the Apple Dev center works.
Most of the time when I visit Apple's sites now, I just assume that what I need to find will either be buried in a convoluted maze, or simply won't exist, and I'll find myself on a "this has been deprecated" 404-style page which takes me someplace only loosely related to what I was looking for. So I end up back at google to try to find a copy of the information either cached somewhere or offsite.
Simply being an Apple developer is a chore. Keeping up with yearly certificate expirations is taxing when you are contracting for several clients. And they never really worked out an easy way to allow several developers to share certs. I just assume now that the other developers will invalidate whatever shared cert I made.
The situation is bad enough, and exacerbated by Apple stubbornly refusing to see the flaws, that I wish a startup would encapsulate the friction and just take care of all the minutia for me. I should never have to personally deal with provisioning. Anything short of a one click submission to iTunes Connect is reminiscent of all the TCP/IP details that we used to have to put in our modems in the dialup days, when all that should have been required was a phone number and passcode. I can't gently forgive them for it. So I think this downtime could be a wakeup call for them that the inefficiencies in their system are even costing them now.
We ought to also look at the inefficiencies of the Android system while we're here. 35% of users are still on Gingerbread! You can't really expect to earn money as a developer if you ignore 35% of your target market, with iOS we have over 90% running iOS 6 and only about 6% running Android 4.2, which means that developers can't take advantage of a new Android feature without leaving behind the majority of their market, or creating multiple versions and then on top of that, having to test on a myriad of different hardware configurations. The fact also remains that Android users are generally cheap -- they don't like to pay for apps. So you have a highly fragmented OS environment, coupled with a user base that, in generally spends much less that iOS users and, on top of that, you have a royal mess in the copy-protection scheme used in Android -- which had to be disabled in Jelly Bean due to it breaking apps.
Of course, the security in Android is top notch! Great job on that Google.
If we want to talk inefficiencies with Apple, we certainly can, but to ignore the Google mess is disingenuous.
As far as the effect of Apple's "inefficiencies," is it really affecting them? Are people still buying apps and computers?
My last point is that the assertion of Apple "stubbornly refusing to see the flaws.." That's interesting, because unless one works for Apple at a level high enough to be involved in the conversation, that suggestion is merely conjecture. That's right up there with the pundits being disappointed that iWatch has been delayed, despite having no proof or any acknowledgment from Apple that even such a product exists.
There's an easy solution to not having to deal with Apple's "inefficiencies" -- don't deal with Apple and go make your money with all of the people paying money for Android apps. Or, respond to one of the hundreds of job listings at Apple and do something about it.
I completely agree with all your other points though. :)
if you don't like android, that's fine, but it's a total digression from the thread.
I realize that Android is even worse (I wouldn't be able to test on the hundreds of devices it runs on). I'm hard on Apple because they have billions of dollars. Two policies that would fix their site for me:
* Throw provisioning in the wastebasket. They forgot the first rule of security: if you leave it up to the user to learn it, it's insecure. Imagine how easy it would be to steal the private keys from a developer's machine, or from the email they used to send the key to someone on their team. It's fine to let devs sign their binaries. But don't impose that as a requirement. Xcode should automagically jump through whatever hoops are necessary to sign a binary to run on the device you are building for, and also sign it when you upload it to the app store (with credentials it receives from iTunes Connect using your username and password). To me, there is no excuse for the way it runs now. I understand that they rushed it through to get the iPhone released to the public, and that they perceive their current policy as more secure. But they are wrong. It's just more work.
* If they are going to deprecate something, don't get rid of the original page. This is web design 101 and I just don't understand how it keeps happening.
I'd really love that Apple proves me wrong on this one and comes clean on the problem, the cause and prevention measures being put in place so this won't happen again, whatever it is.
In another world HN would be up in arms about how to manage downtime, how this is u acceptable and how they are going to switch to somebody else immediately. But not for apple because they have no choice...
I did have the same password for about three years so it didn't seem too odd. Of course I double-checked the url and it looked good. Also I waited for a few days in the hopes that someone else would notice if this was a scam of some sort.
Unfortunately after updating my password I forgot the new one. At least I think I forgot as my new password (as best I can remember it) doesn't work.
Last Thursday, an intruder attempted to secure personal information of our registered developers from our developer website. Sensitive personal information was encrypted and cannot be accessed, however, we have not been able to rule out the possibility that some developers’ names, mailing addresses, and/or email addresses may have been accessed. In the spirit of transparency, we want to inform you of the issue. We took the site down immediately on Thursday and have been working around the clock since then.
In order to prevent a security threat like this from happening again, we’re completely overhauling our developer systems, updating our server software, and rebuilding our entire database. We apologize for the significant inconvenience that our downtime has caused you and we expect to have the developer website up again soon.
World's premier closed-source shop: (presumably) gets hacked; goes down; stays down.
Github, Rubygems, Linux Kernel, etc. get hacked; restore from SHA256SUM'ed backups; keep moving.
Turns out what used to be called "hobby" projects matter, because code made without love has a smell, and no one does a "hobby" for anything but. (Remember the 'ama' in 'amateur') (ok ok so kernel.org was down for a while. But remember all the heavy lifting done by git to keep those commits clean. It was just the server, not the data.)
Last Thursday, an intruder attempted to secure personal information of our registered developers from our developer website. Sensitive personal information was encrypted and cannot be accessed, however, we have not been able to rule out the possibility that some developers’ names, mailing addresses, and/or email addresses may have been accessed. In the spirit of transparency, we want to inform you of the issue. We took the site down immediately on Thursday and have been working around the clock since then.
In order to prevent a security threat like this from happening again, we’re completely overhauling our developer systems, updating our server software, and rebuilding our entire database. We apologize for the significant inconvenience that our downtime has caused you and we expect to have the developer website up again soon.
So, you're telling me that I need to go read his article, earn him pageviews and ad money and come back here to discuss about the issue? I think a Ask HN post would have done the job, much better, no?
Just saw your edit:
>(which no one has to read)
wut?
No one has to read the article, and it seems like a lot of people don't read the article before commenting. The comment box doesn't give you a quiz on the article before letting you comment.
I remember a lot of discussions a year or two ago when marco was very vocal about the reasons he didn't have comments on his blog, and would prefer to have all of these on HN for e.g.
slowdown's comment goes the other way round, on why HN should care about commenting on marco's blog. There is another thread [1] with 138 comments and more quality opinions and speculations than anyone should need, Marco's speculations are also represented in the top comments. Agree or not with he's stance, it's a valid point IMO.
I think it's fun to see this kind of reaction on why some contents should be commented or not, and the motivations to push a site or another.
That thread is quickly sliding down the list and is already off the front page. I don't think a new one is out of the question.
A way to navigate to new unread entries would be nice.
Sometimes I really wish NNTP wasn't quite so dead.
I'm sure Apple are as unhappy about whatever has happened as the rest of us (likely much more so), but I think at least some communication from them about it would be in order.
Well, an `App'(, the name of which I would not like to identify, ) which was installed using Safari exploits and whose intended use is to help users search and install apps free of charge from AppStore, is still up and running.
I guess there exist various exploits up and down the App Store chains, till now.
iOS is in a big transition here. You can't even update apps at all unless you now include 'widescreen' support, for example. If you don't, iTunes reports an Invalid Binary (no default 586 image, etc).
So I would guess a huge overhaul, and typical Apple, is taking care of that vs. arguing or commenting on theories.
A design overhaul wouldn't require the dev centre to go down at all - they could just prepare all the assets etc on testing servers and switch them over when they are ready.
Given the normal warning given on any maintenance, and the obvious negative consequences for Apple's business of any extended outage (extended in this case being over a day or so), this is unintended, and most likely caused by a security breach. I think we can safely rule out a design overhaul unless Apple are incredibly incompetent.
NB itunesconnect is still up (the bit which deals with app upload, itunes store metadata etc), only the dev center - dealing with certs/device registration/distribution etc - is down.
nwh's comment ( https://news.ycombinator.com/item?id=6078854 ) says they've got a lot of different systems running, maybe they're trying to unify them to be on one system, making upgrading/changing easier in the future?
No planned migration or consolidation should take several days of interrupted service, it's just not necessary unless something goes horribly wrong.
But there are other instances where the store will go down outside of those periods. Sometimes it's for maintenance, but more often than not a new or updated product appears (e.g. a product line gets a speed bump across the board).
Don't forget that developers get 30%, when Apple show off (rightfully so) a huge sum paid to developers, they've been paid significantly more than that - developers seriously matter.
He is being Captain Obvious.
Including the gem to "set some time aside" as developers, because we might have some work to do after the site comes back up.
Everything in the comment is what men wiser than us called "idle speculation".