408 karma · joined August 16, 2010
If they actually took part that seriously, most identification could be done with a PIN or a password or whatever and the serious identification could be reserved for people who've actually forgotten.
Today is July 31, 2018 in the United States, which adopted the Gregorian calender per the act of British parliament entitled "An Act for Regulating the Commencement of the Year; and for Correcting the Calendar now in Use" (24 Geo. 2 c. 23) by skipping September 3-13, 1752 (obviously this was prior to the American revolution).
In the Julian calendar, there are leap days every four years. In the Gregorian calendar, there are leap years every four years except every 100 years except every 400 years. That is, 2000 and 2004 are leap years, but 1900 is not a leap year.
Since 100, 200, 300, 500, 600, 700, 900, 1000, 1100, 1300, 1400, 1500, 1700, 1800, and 1900 were leap years in the Julian calendar but not the Gregorian calendar, one must subtract 15 days to get to the Gregorian date to get the Julian date.
Today is July 18, 2018 in the Julian calendar.
The Soviet Union adopted the Gregorian calendar in 1918 by skipping February 1-13. They were the last. This is why the famous February revolution took place in March and why the October revolution took place in November. (Though I noticed Reuters announced it had been 100 years last year on the wrong day.)
Mainframes are weird, but I really doubt they don't use the Gregorian calendar whatever the text on the screen says.
If that doesn't work, do stty status ^t first.
This is SIGINFO; it's been in BSD for a long time, but isn't in Linux and is relatively unknown nowadays. Quite a few BSD command line programs will respond to it.
With a few exceptions (like-kind exchanges come to mind), you owe the capital gains tax when you dispose of the property. That you continue to take on market risk afterwards does not enter into it.
The market works because there are always people willing to take both sides simultaneously. To some extent this is driven by people who have different opinions. This is also drive by people working on different time frames. Somebody who thinks it will rise in the next 10 years may buy from somebody who thinks it will fall in the next 10 minutes.
When there are not hoards of people willing to take both sides, price starts to move around erratically. Ultimately Spotify isn't very widely held. I doubt any of the current holders are interested in trading frequently. They want to make their trade and get out. So who is selling on the first few days? Market makers will work both sides of the market as they always do, but they won't hold a large short position against a rising market. Instead the spread will be large. That's why I suspect we'll see some wild price swings before the market settles down.
On the other hand, you could say this about any IPO. And it's true that the first few days are often rocky. It remains to be seen if Spotify's plan produces a more rocky start than is usual.
They certainly could (subject to market manipulation laws). Would it work? Probably not. There will be sellers willing to sell short naked (intending to buy back by the end of the day so they don't have to deliver non-existent stock). I'm sure there's many holders, since Spotify has been around for a while and presumably has some sort of stock compensation program. Will they all refrain from selling? No, because somebody wants to renovate his kitchen.
The IPO price is the price at which shares are sold by the company to the public and represents the new money invested in the company. Then on the morning on which trading opens there is an opening auction as described. Ideally this price is near the IPO price, meaning that neither the company nor the investors left money on the table.
Spotify is proposing to skip the IPO, and not raise further money. They must think that their stock is already widely held enough to support trading, and that they have no need of further money.
It will be interesting to see what happens if they go forward with this. While the mechanics are no different than any other day of trading, I suspect the type of trading will be very different. Currently all holders of Spotify stock are long-term investors, simply because there is no market. Until traders acquire enough of it, liquidity will be bad and the price will probably jump around a lot. In addition, many people will want to invest, so they will buy. Will current holders want to sell? I suspect they will want to watch trading instead of selling at the first possible moment.
I think we'll see a rapid rise in Spotify's price due to high demand and lack of supply. The current holders will undoubtedly be looking to reduce their stake. Will demand keep up as they begin selling, or will price rapidly fall as trading becomes, for lack of a better term, "normal."
While catting actual random data is contrived, using ssh is not. What if the connection is broken while you're in vi. Vi switches to the alternate screen and then scrolling stops working. If you don't know what happened it's not clear why. How can ssh fix this other than acting like tmux and parsing every terminal command sequence? I'm not convinced there is a simple fix.
This doesn't even get into encoding issues. Some UTF-8 sequences are terminal commands. The UTF-8 encoding for U+00DF (the German eszett) contains a sequence which will cause some terminals to wait for a termination byte you wont ever send.
Plan 9 had the right idea: do away with terminal command sequences altogether. But that only works there because you can take your "terminal" and turn it into a GUI window.
However the shell supports more line editing. I bet you can press the left arrow and edit the middle of the line. I bet you can press the up arrow and get the last line typed. I bet you can press ^A and get to the beginning of the line. The kernel doesn't do any of this, and you can't do it in cat. What happens is the shell turns off line editing. Then it gets all input unprocessed, and can decide what to do on it's own. This is why Chris Siebenmann put the PS in there.
Because it's his computer? Who else's job might it be? He only has a few options: fix it himself, pay someone else to fix it, convince someone else to fix it for free, or do without sound.
It's the same with less knowledgeable users, except they don't have the option to fix it themselves.
It's not just foreigners. Even us on the opposite side of the United States have no idea what El Capitan or Maverick is or means.
My impression was that Xorg has obviated the need for manual configuration in all but the most extreme cases. Multiple monitors are easy with xrandr, but I'm not sure how multiple graphics cards will work.
A great part of IRC is that there's no registration. There's no identity.
And there's the problem. I don't use any of those four sites regularly, but I have visited all of them. Hyperlinks provide for that, and they (a) don't exist or at best would be awkward in a native app (not that webapps handle them well to begin with, though all of the above do allow for them at least) and (b) work between apps, platforms, and what-have-you. If I got a link to some image, <160 character sentence, comment thread, or song and was prompted to download an app, I would probably not view that content instead.
> exec: Allows a process to call execve(2). Coupled with the proc promise, this allows a process to fork and execute another program. The new program starts running without pledge active and hopefully makes a new pledge().
A very important part of pledge's design is that a parent can be more restricted than its child. This isn't a sandboxing mechanism. It's intended to mitigate the dangers of some other vulnerability leading to remote code execution. With pledge, even if you get into the system you may not be able to make all the syscalls you need.
Sure it doesn't have the features of Vim or Emacs (and some would say that's a feature!), but it's perfectly serviceable if you're okay with vi's modality.
The article would have been much better technically if the movies didn't load or play until asked for. I'd argue it would have been better still if the author removed half of the movies and expanded on his point more. I didn't get much more than what it says in the title. Is it good or bad to hear so much in a library? What are the differences between buildings designed by architects that pay attention to sound and those who don't?