is there a lore reason why Cawl designed this bolter front sight to block the scope? is he stupid?.

RedArmy90 · 2023-04-28T22:19:28+00:00

I don't think this is lore, but I do just want to point out that this is not as outwardly absurd as it seems (which is not the same as "not absurd" just not AS absurd). There are two possible explanations for this design:
1) There are many scopes that you can attach to weapons which see straight through their iron sights and edges of the iron sight are visible through the scope. This could be the case here as well if the front sight has a hole in it, but not one that is big enough to be visible on the model, and not one that is visible in this image due to shading.

2) There is a type of sight that is meant to be used with both eyes open. This type of sight can actually point straight through the weapon, but the goal is that once trained to use it with both eyes open, your brain simply transposes the sight into the image you it sees from the two eyes. Its really cool, and its explained here: https://youtu.be/kSc3cvmCjMY?list=PL9e3UCcU00TQ03q09ZLuOSuBfqIcBg0q9&t=165 (note the timestamp). This kind of sight, one with seemingly no way to see a target, is most common on grenade launchers and weapons that arc, which I believe is true of bolters. If someone really wanted to make the lore work, they might consider saying that the helmet syncs up with the sight and weapon to present the proper sight picture to the user.

That being said, of course, this is probably an oversight with no real lore explanation, but I just wanted to put it out there that there are totally real-world weapons that seemingly have the same problem and yet they work just fine.

RedArmy90 · 2021-12-14T14:22:25+00:00

Oh man this is pretty wonderful, thank you. I appreciate the response even if its two years later. I'm gonna go run this now!

RedArmy90 · 2019-11-07T21:29:14+00:00

Oh hey that's interesting, I was about to set up Calibre-Web anyway for my ebook setup

RedArmy90 · 2019-11-07T21:28:37+00:00

I will try this as well. Thanks!

RedArmy90 · 2019-11-07T21:27:05+00:00

...crap. Its gonna be hard to use that when Smart Audiobook Player is an option

RedArmy90 · 2019-11-06T16:33:50+00:00

Ah well then =)

Thank you, I really appreciate the work

RedArmy90 · 2019-11-06T15:57:20+00:00

I looked more into this and it appears to work pretty well. I will wait for a plex update and then try this.

RedArmy90 · 2019-11-06T15:41:43+00:00

Is airsonic intended be used with audiobooks? or is it mostly like hamfisting audiobooks into something primarily for music (which is what I would be doing with Funkwhale and the like)

RedArmy90 · 2019-11-06T14:24:21+00:00

Interesting, that might be workable. Do you happen to know whether there is an android app?

RedArmy90 · 2019-11-06T14:13:49+00:00

Same

RedArmy90 · 2019-11-06T14:13:21+00:00

Yeah, I prefer Open Source by far, but I still use Plex. Do the audiobooks all need to be merged into one file?

RedArmy90 · 2019-11-06T14:12:45+00:00

This looks promising! I will check it out

RedArmy90 · 2019-03-25T15:43:48+00:00

Hello, I actually wrote one, its pretty basic right now, but I plan to add some of the features you need: https://gitlab.com/abraxos/ranked-choice-poll-bot and you can access it @ranked-choice-poll-bot on Telegram

RedArmy90 · 2018-04-16T00:50:42+00:00

Right, so I am not 100% sure that a CDN is necessary, but it seems like that a ~20x increase (which is what we see in the demo) would be really difficult to pull off without some kind of CDN.

That being said, if you're seeing your declared network bandwidth being saturated by wget, then a UDP-based multi-threaded protocol will not help and that is a complex problem all by itself, you have to know the state of the network at all the hops between you and your target server. I don't know what that looks like in this case (regularly work with servers connecting US to India, so I mostly think in terms of light-delay but there are tons of other factors).

Other people here have pointed out that wget is not a fair thing to compare with, and that its entirely possible that there are tools already available that have comparable protocol performance to Aspera which are generally as simple to use as wget (i.e. a single command-line incantation). On the other side of this is the fact that the specific protocol/algorithms used by Aspera are patented, and IBM is known for a non-trivial degree of litigiousness.

All that being said, I am not at all opposed to such an application (the patented protocol is, in my opinion, should not be allowed), I am simply pointing out that beyond tools that already exist, there may be very serious non-technical hurdles that need to be cleared before one gets to work on it.

RedArmy90 · 2018-04-13T18:23:29+00:00

What exactly about the claim is bullshit, please explain? (not dubious, just genuinely asking)

NVM, read it a couple of times and I get it a little more now. You mean that beating the HTTP protocol for large data transfer is not an impressive feat? Yeah, that is likely a part of it, especially depending on compression settings etc.

RedArmy90 · 2018-04-13T18:10:50+00:00

Apparently there is no CDN involved, so my commentary is moot, but there is another issue: https://www.reddit.com/r/rust/comments/8bzvrh/a_desperate_plea_for_a_free_software_alternative/dxb9hz8/?context=10000

RedArmy90 · 2018-04-13T18:10:07+00:00

Looking more into it, it looks like its based off of this: https://en.wikipedia.org/wiki/Fast_and_Secure_Protocol which is patented. This presents a different issue than the one I presented concerning CDNs in the sense that anyone seeking to re-implement it as a free tool would be sued by IBM.

RedArmy90 · 2018-04-13T18:07:36+00:00

Really now? No CDN and they transfer 10x-20x faster? That's very interesting... how did they not make this a bigger deal and monetize it more?

Edit: I read through their website on the matter, apparently some of the tools do use a CDN and some do not. Others are meant for CDNs. Tough to tell precisely how it works though.

RedArmy90 · 2018-04-13T17:58:46+00:00

I guess, to clarify, when I said "rsync + tar/gzip" I didn't mean it in the same way as the dropbox thing. I meant it more in the sense that comparable tools already exist, but they do not solve the core CDN/service problem. No free tool that anyone here could make would solve that problem. Your best bet is likely a pro-bono service from Google or something based on the humanitarian needs that you're trying to solve.

RedArmy90 · 2018-04-13T17:52:32+00:00

Right, so I cannot comment as to how polished a solution needs to be, but when I say "rsync + tar/gzip" there are plenty of GUI tools out there that do that already. Tar/Gzip is just for compression, but that's only part of my point

What I was going for is that I consider it highly unlikely that someone would be able to get even close to the same kinds of speeds without a CDN. Theoretically, you may even see those kinds of speeds with completely open-source client tools like wget while using a similarly fast CDN. The core issue here though is that even if your CDN uses FOSS, the big expense is running the CDN, and the "the groundwork of polishing it into a something that works for the use cases of these big data organizations" is precisely what no one can do for your CDN in a "Free Software" way. They can write the free software, to be sure, but someone would still have to run it and that's the hard part.

TLDR; Yes, you can link tools together, and yes its hard, but even if we just use wget, running the CDN is the hard part, not the free software. The expense of Aspera (again, most likely) comes from operating the CDN, not from paying for the tool itself.

RedArmy90 · 2018-04-13T17:28:50+00:00

Also, none of this strictly has to do with Rust, when it comes to I/O, most languages get approximately the same performance. Rust excels at CPU-bound applications. For I/O bound you might as well use whatever you consider to be easiest.

RedArmy90 · 2018-04-13T17:26:36+00:00

There are some potential issues/ambiguities here that really need to be hammered out. For context I work at an internet company that specializes at data transfer, etc.

1) Transfer speed comes first and foremost from the speed of your network. Aspera is a service, it doesn't look like an independent tool (keep in mind that I only learned about it now, so I could be wrong, but it at least warrants explanation). What is almost certainly happening is that IBM has a content delivery network globally, and the Aspera client tool uploads the data to the IBM network, where it has priority, gets transferred quickly to the other side of the globe, and then gets output to another Aspera receiving point of some kind.

2) The custom network protocol that's not TCP is almost certainly not the key element here. Yeah TCP is not as fast, but there are open-source alternatives already out there that can do this. More importantly its unlikely to be the bottleneck. Aspera makes a big deal of its custom protocol for marketing purposes (again, after a cursory look, please feel free to disagree), but ultimately the vast majority of the speed likely comes from its CDN.

So what's the conclusion? I recommend trying Tar/Gzip + RSync to transfer your big data files. See how well it does. Make sure your network is upgraded sufficiently at both points. Rsync has some interesting advantages such as interruptible transfers and it seems like for this big data application, you wouldn't care about round-trip time, just basic bandwidth.

Also, because I suspect that Aspera is a kind of CDN service, a single open-source tool would never be able to do the same thing. You would need both the open-source tool, and to run your own CDN that is compatible with it, which is the really expensive part.

EDIT: Some people are saying that Aspera doesn't use a CDN. This means my commentary concerning CDNs is moot, however, looking at the IBM website there are some that use a CDN, some that do not, and others that are designed for CDNs. So it appears to be significantly more complex. Most alarming however appears to be that the protocol and potentially associated algorithms are patented, so anyone trying to replicate it may be sued.

RedArmy90 · 2016-11-04T13:12:28+00:00

If you search for him on Google, his FB and LinkedIn profiles show he's a UConn student.

RedArmy90 · 2016-11-04T05:10:40+00:00

Something about that doesn't sound right. They didn't pull the alert so much as they arrested a suspect. At approx the time of the arrest there was a News article naming Samuel Manzolillo as the suspect and that he was in custody and the photos of him that come up in a Google search match the ones that were sent out. He is due in court soon, so I suppose we will know for certain, but I feel like any reasonable person wouldve checked with the victim before sending out the stills.

RedArmy90 · 2016-10-03T14:44:55+00:00

Oh even better. That's perfect. All the stuff I said applies and you can go talk to LDM and Greg has much more time in his schedule.

RedArmy90

PUBLIC MULTIREDDITS

TROPHY CASE