HN user

sdkmvx

408 karma
Posts3
Comments112
View on HN

I just want a world where you go into a cell store, and they don't tell you they've got a great idea, just make your PIN your birthdate.

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.

Are you sure?

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.

On BSD (including Mac OS X), you can also type ^t at dd, and it will print status information.

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.

Of course that's not true. All you must do is find a counterparty willing to take Facebook stock as payment for Amazon stock. (I am not aware of any exchange listing such a contract, but it's certainly possible over the counter.) And if you do, you will have to pay taxes on the gain and will have a new cost basis in your Amazon stock.

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.

Well the IPO price is the price at which the company sold new stock to the public. Then the price moves however the market causes the price to move. They're not going to sell new stock to the public, but the price will move however the market causes it to move.

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.

There is none. On the first day of trading there would be an opening auction as is done with every other stock listed on the NYSE. Prior to open, everyone interested in trading submits his orders. Then as many shares as can be traded are traded at the price at which the maximum number of shares can be traded. That is, the price is determined by supply and demand.

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."

cat could tell but it probably wouldn't be a good design. Calling isatty is easy, and I think GNU cat already does so and buffers differently. But how can it tell what raw binary data did to your terminal? First you'd need to program all the different terminal types into cat (probably by using termcap) which isn't great simple "Unix" design to begin with. Then you can't just reset the terminal after running cat. You need to see if the binary data screwed up the terminal. That isn't in termcap and is probably intractable in the general case.

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.

The shell needs to print a prompt and read input. This is I/O, which involves the kernel. The shell is (when running interactively) attached to some terminal. These days it's usually a pseudo-terminal with a terminal emulator like xterm on the other end. (With some exceptions) the read syscall on a terminal does not return until there's a newline. The kernel only implements simple line editing. You can kill the whole like (^U) or erase the last character (^H i.e. backspace). Traditionally kill and erase were @ and # which you may see in some old documentation. On a hardcopy terminal you could type daat##te and it would run date. If the right flags are set, instead of outputting the erase character, Unix will back up, print a space, and back up again as described.

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.

Okay, you got burned by Pulseaudio. But why was it your job to debug these issues?

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.

Lawyers are rather fond of such doublets and triplets. Consider free and clear, null and void, terms and conditions, and even law and order. The origin of a lot of legalisms is the historical confusion over language in ancient English courts: Latin, French, or English? Most odd legal grammar is actually of French origin.

MacOS Sierra 10 years ago

And for OSX naming... I thought Apple is an international company. Tiger, Leopard etc was easy to read and understand as a word for us foreigners and now what? El capitan? I must think their vision is just getting narrower naming a OS to some local name they thought was cool.

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.

I haven't needed to configure X on OpenBSD at least five years now. The X server does that automatically, just like on Linux. For the record, I haven't needed to on FreeBSD either, but I've run that much more sporadically, so take that with a grain of salt.

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.

Just so you and others know, the L in ALSA stands for Linux. It doesn't run on DragonFlyBSD. I think DragonFlyBSD uses a re-implementation of the OSS API that they inherited from FreeBSD. The other BSDs use /dev/audio, which was originally a Sun API.

Some news from LWN 10 years ago

I like that. It helps me to see where one comment ends and another begins. I can't stand these modern sites which have no borders at all, making it very hard to visually distinguish separate posts.

Some news from LWN 10 years ago

It gets even less useful as time goes on. Eventually it'll say one year ago. A timestamp would give the exact time rather than a huge range.

When you join ssh-chat, not only do I know who you claim to be, but I can also permanently and securely attach an identity to your connection without any user intervention on your part.

A great part of IRC is that there's no registration. There's no identity.

It's not being updated at all. You are looking at the version in ports. This can be updated to a GPLv3 version (as 4.9.3 is a GPLv3 version) just fine. I don't know why it isn't; perhaps there's some porting problem and no or little demand. The version 4.9.3 is the same version that was present in OpenBSD 5.9 and probably several releases back. The system GCC is 4.2.1 plus OpenBSD patches. It has been for some time. This will not be updated to a GPLv3 compiler.

I've had the same results as you, though without the glasses. I really don't understand why people prefer such blurry fonts. The biggest practical problem I've had with turning antialiasing off though is badly hinted web fonts. Sometimes bars or stems just outright disappear.

regularly used as Facebook or Twitter or Reddit or Soundcloud

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.

OS X's libsandbox is much closer to SELinux. It's MAC-based (mandatory access control not Macintosh) and is actually TrustedBSD under the covers. Pledge simply disallows access to syscalls and paths outside a list. It's not very fine-grained. It also resets on exec, so it can't be used as a sandbox or container.

From the manpage:

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().

That won't work because exec resets 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.

I have to disagree. There were movies every two paragraphs. It is hard to read when something is moving around an inch from the text. Further the movies took forever to load. I sat and waited 10 minutes for one. So I really had big panes that were still for 15 seconds and then suddenly jumped.

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?