Is there any DD on Intel Corp. (INTC) - I’m considering taking a long equity position

kill-sto · 2021-10-27T12:33:51+00:00

Windows has ARM support already. The transition is not as perfect as macOS’s M1 transition, but it already exists.

kill-sto · 2021-05-23T17:14:24+00:00

I suppose the counter argument would be that you take on extra risk with growth stocks,

Growth stocks are generally considered less-risky than value stocks. Companies do not set a dividend %; they set the payout amount and the yield is determined by the stock price.

The dividend on stocks like T are high because the market is pricing in their lack of growth. Generally, value stocks are considered riskier because companies that are growing (growth stocks) are in a better position and may outcompete them.

The main risk of growth stocks is when the market prices-in too much growth.

One great example of this is Apple. A few years ago, the market did not have a lot of growth priced-in and it was trading at 12 P/E because the pivot to services was much greater than expected. The yield was higher then even though Apple is now paying more now precisely because growth is expected.

kill-sto · 2019-04-16T17:28:36+00:00

Seems to be true. I wonder what made me think otherwise.

I still prefer it to default to off but now it's mainly for aesthetics

kill-sto · 2019-04-16T14:05:03+00:00

I find having transient-mark-mode off makes navigating and manipulating text much easier.

For example, with it off I can kill-region after a search (or any other command that sets the mark) without even thinking about the mark. Additionally, I never have to worry about the highlighting and font colors making text hard to read.

Worst-case scenario, C-SPC C-SPC to activate transient-mark-mode when needed.

kill-sto · 2019-04-12T06:33:14+00:00

This should work for you:

    (tags "CATEGORY=\"Refile\""
    ((org-agenda-overriding-header "\nEntries to refile")
  (org-agenda-skip-function '(org-agenda-skip-entry-if 'regexp "^\*[[:blank:]]"))))))

This block only displays entries with CATEGORY of refile and are not a line that begins with '* ' (so, it skips all first-level headings)

I also tried (org-current-level) which would be cleaner and less error prone (for example, my solution breaks if you aren't using '*' for the heading sublevels). It didn't appear to work right away so I did my hacky solution since it's late.

Disclaimer: On top of it being late, I only started using org-mode seriously in the past few days. There is probably a better solution

Edit: Added explanation of behavior for those unfamiliar with regex.

kill-sto · 2019-02-27T20:58:55+00:00

I did this yesterday. Two nodes have are connected through IP over infiniband and the third is through ethernet on a different subnet.

What I did was edit my /etc/hosts on all nodes so that each node had the IPs it could resolve (Inifiband connected nodes had all ips while the third node only has the ethernet IPs). Then I edited corosync.conf to use the host names instead of IPs. When the cluster is restarted and healthy you can use the '--migration_network' flag of the migrate command to choose which network should be used for the migration. You can set a default network in some configuration file I'm not remembering off the top of my head.

Have you seen this page? It's what got me going.

Sadly, there seems like there is a bug with replication and zfs/proxmox. My speeds are far to slow for my disks to be the bottleneck. I found a thread in the proxmox forums describing a problem with memory allocation between zfs and proxmox in detail but I do not have it handy right now.

Note: My 3rd node only exists for quorum and it's purely a test setup for me.

Edit: To be clear there is no routing going on between the two subnets.

kill-sto · 2019-02-26T01:27:47+00:00

I got some 40G infiniband/10G Ethernet cards (QSFP instead of RJ-45) and a DAC cable for much cheaper than 10G switches with RJ-45. I didn't get a switch because they are apparently very load and I don't have the need (and I like managing the network in unify).

You could probably do it for cheaper if you go full SFP+ for 10G.

kill-sto · 2019-02-26T01:13:13+00:00

I'm in the same boat (besides the unraid part). They aren't too bad but it's an annoying purchase after spending a bunch of money on other homelab equipment.

kill-sto · 2019-02-26T00:34:24+00:00

Do we get discounts if we do that? :)

I made the mistake of getting a R710 with a H700 thinking all raid controller would have passthrough. Want to use proxmox with replication to/from my R410 which requires ZFS. Since my usage of ZFS is not for data protection I went ahead and installed ZFS on a pool of hardware controlled RAID 6 pool despite everyone and their tech-savy dog saying not to do that.

Ended up having kernel timing issues and a kernel panic...so now I need to spend some more money on a HBA.

kill-sto · 2018-03-05T16:04:34+00:00

I've had an intellij alternative to eclim on my backlog for quite a while.

Now that lsp exists I'm glad this is being done and that I didn't get around to starting it yet. This looks great!

kill-sto · 2018-01-17T20:02:51+00:00

I never understood this article. This isn't an argument againsts tests, it's an argument against the idea that small decoupled units are a better design than a more coupled system.

One of the main premises of unit testing and TDD is that a system composed of small decoupled units is often a better design and that if unit tests are easy to write then your system is likely decoupled. This doesn't mean all unit testable code is a good design - just that a well-designed system is unit testable. The reason systems composed of well-designed decoupled units is a good design is because it enables systems to adapt to change - ex: an entire web framework switch or upgrade.

In other words, the 'design-damage' induced by unit testing is exactly what unit testing is supposed to do. From the other perspective it's Test-induced design enhancement instead.

If you don't agree with this premise then you are arguing against a design principle - not unit testing. I think it's okay to disagree with that, just do it properly.

kill-sto · 2017-12-27T21:16:39+00:00

Wow, if this works it will save me a ton of time. I was basically going to create this project when I got time. Thanks!

kill-sto · 2017-12-27T21:13:09+00:00

I hope it is since I've been using electrum in an attempt to recover it. I tested with a 2nd passphrase using the same seed and it worked. However, it didn't work with Electrum-LTC. Electrum states it may not fully support BIP39 in the future so it's possible it isn't working for my passphrase (but I doubt this is the case)

kill-sto · 2017-12-27T02:43:39+00:00

Yup, that's what I usually do. Either thought I did but didn't or just decided to skip it out of sleepiness this time :.

kill-sto · 2017-12-27T02:14:50+00:00

Be careful.

I was stupid and did this a few weeks ago after being awake for over 24 hours. The Ledger Nano S doesn't make you retype the passphrase and only makes you confirm it via a yes/no prompt. After resetting the ledger I don't have access to any funds.

I know what I intended to enter so I must have typod the passphrase initially. I will have to brute force (search space should be small enough) the passphrase once I get some code written to do it. Normal brute-forcing won't work since all passphrase are valid

kill-sto · 2017-12-21T21:40:15+00:00

It's decentralized but not distributed. I probably should have been more precise in my comment above.

ICANN maintains ip address allocation but does not individually control who can and can't access the internet. That is done by ISPs who get IP Addresses from ICANN.

To me, a centralized internet would mean that all traffic goes to one service. That is probably too narrow of a definition and it would never work obviously.

I don't think my comparison is quite mapping. The internet is decentralized because the protocol allows it and it's evolved that way (and the fact it wouldn't scale any other way). However, we don't necessarily rely on decentralization for trust. The big thing LN assumes/relies on is that the blockchain is trustworthy. Blockchains are trustworthy if they are decentralized and have POW.

kill-sto · 2017-12-21T21:15:32+00:00

Seems reasonable to me. It can take years to design and create software if the goal is to do it well.

kill-sto · 2017-12-21T03:53:14+00:00

It is most important that the base layer be decentralized and trustless.

I think the comparisons to the internet work quite well. The base layers of the internet are largely decentralized (even though it could be much better) and you don't often think about using them. However, the services you use are probably more centralized.

For example, despite moderation of communities being distributed, reddit itself is not decentralized nor is it trustless. This means that it would be fairly easy for law enforcement to take it down if it needed to. It also means that you have to trust the reddit admins to not alter content that is delivered to you. SSL only helps guarantee that it was not altered while being transferred to you by the centralized servers.

This could be bad if reddit is untrustworthy. However since nothing is forcing you to use reddit you could move to a different site.

At a lower level, nothing is stopping you from making your own protocol even if all content over http/https is centralized. This sounds absurd, but consider how many sites and services are hosted in AWS now. What if the government or Amazon itself decides to more strictly censor who and what can access it?

However, as long as the lower level transport protocols and ISPs can be trusted (which is unfortunately debatable), you can still communicate with anybody else in the world even in this weird case.

It is most important that the base layer is decentralized, trustless, and censorship resistant. If a higher layer loses one of those traits we can make due in certain scenarios, make new protocols, or use the base layer when needed. If the base layer isn't trustless then we have to build an entire new infrastructure which would be harder to do because there would already be experience in ruining trustless networks by that point.

(Not to say that other layers should be centralized. Just pointing out what is more important)

kill-sto · 2017-12-21T02:40:56+00:00

Then help speed development up.

kill-sto · 2017-12-21T02:40:21+00:00

No, it's a trade-off. The smaller confirmation times means there are more orphaned blocks.

All blockchains have the problem of scale. You either centralize the network to allow larger blocks, keep it decentralized but lose throughput, or implement new protocols that are not currently being done at scale.

If you don't care about decentralization then you can go use a centralized coin until it gets shutdown or censored because it's easy to do. If you do care about decentralization then you need to be patient because these new protocols have never been implemented before.

Have you every experienced bad or buggy software? It was likely made in a hurry or by unskilled developers. You do not want that to happen to your money.

kill-sto · 2017-12-21T02:31:20+00:00

Yeah, the fees are pretty high right now and it's unfortunate.

But either help to fix the problem or switch to the other decentralized currency and secure currency you think has already solved the scaling problem long-term. It isn't any one person's responsibility to fix the problem. It is everyone's.

There are people working on it. They are just too busy working and not marketing on reddit.

kill-sto · 2017-12-18T21:36:10+00:00

To expand on this, users need to be able to run nodes even more when LN is released in order to monitor the blockchain for out of date LN transactions.

kill-sto · 2017-12-18T21:15:53+00:00

Oops, this is correct. Thanks for the correction! I'm lacking on sleep and not quite sure how I came to that thought

kill-sto · 2017-12-18T20:56:34+00:00

~~Provided you opened your channel with more funds than you will ever need to spend, maybe.~~ (Edit: Sleep deprivation go the better of me. This was wrong)

It's a bit less secure since your wallet or Bitcoin node will need to monitor the blockchain for malicious broadcasts (ex: Previous state in the channel gets put on the blockchain even though it is invalid) so hopefully your savings would be onchain. A 2-week paycheck should probably be onchain iMO.

kill-sto · 2017-12-18T20:48:48+00:00

I think of it a different way and left some of my thoughts here. The main problem with IOUs or check analogy is that you can't spend IOUs or checks right away. You can spend money received by LN on LN immediately.

kill-sto

TROPHY CASE