Straight up... straight down. No orbit. Nothing to see other than "tourist" flights for people who want to see what space is like but without weightlessness.
To judge a suborbital launch for having not made orbit is to criticize a Ferrari for having not reached 30,000' above a test track. The goals are different, and the metrics are different.
Blue Origin is moving through a planned series of test flights necessary to bring untrained astronauts into space on their own custom hardware with an improved margin of safety.
Comparisons with SpaceX will again become reasonable when either a) One of the companies launches a person into space, as both aspire to do, or b) Blue Origin begins an orbital campaign.
Congratulations, Blue Origin. You crushed it again today.
They aren't going to space! The thing barely makes it to to edge of the atmosphere. How long are you gonna keep apologizing for them? There's literally no technical innovation here.
I'm sorry, it's not technical innovation. If someone invents a horse and carriage when the automobile is already in existence, the horse and carriage is not innovation. The poster who has been downvoted out of existence is correct.
> while the booster drops back down, kicking in the landing gear and rocket-powered breaking system to land on the ground, unscathed. The capsule, meanwhile, using a pair of parachutes to coast back to Earth
I think you misunderstand weightlessness. The Blue Origin capsule got to about 75 miles altitude and low earth orbit starts about 100 miles, while Earth's surface is about 4,000 miles from the center of gravity. In other words, the force due to gravity is essentially the same for all of these. Weightlessness is falling, that's it.
I’m sure there’s some period between booster cutoff and the parachutes. They’re not sending the chutes out while the capsule is still on the upward part of its parabolic arc.
Getting to orbit is a big step. You can look at the history of SpaceX and Rocket Lab to get a grasp of what it takes -- hard to imagine a sub-orbital tourism company getting there without an injection of capital. Which, btw, is how Rocket Lab did it: they started with sounding rockets, proved that the knew what they were doing, then got a big round to go orbital.
Virgin Galactic isn’t a profitable company either. They could be, of course.
My point was that you can start with a small company with a well-defined goal and product then continue to grow the vision, as long as you remain profitable.
Yeah I don't disagree here, my point was that Blue Origin's particular goal and product bootstrapping from space tourism has already been tried and more or less failed. Whereas Musk's/SpaceX's goal is to get a Mars colony going, they started with something different than space tourism and it seems to be working out.
While at the same time they've been stripping out vital features or outright disabling them on mobile. It's almost like gasp they don't care about the users but only their bottom line.
I was given an MBP with a touchbar when I contracted with Comcast for 10 months. Hated it.
My personal laptop is MacBook Pro (Retina, 15-inch, Mid 2014).
I will NEVER EVER pay with my own money for a touchbar mac book.
My number one rule when getting a laptop is a good keyboard. Period.
Plus the USB-C drivers for external displays in the new mac books is complete trash. Misaligned windows, constantly forgetting window positions, occasionally completely not working.
The MBP line of computers keeps on getting worse and worse.
I suspect that's a historical tradition made religious due to the fact that it's easy to get "poisonous" pork or shellfish that will kill you if not sourced or prepared correctly.
Yea.... no thanks. It doesn't even have vital social features like looking up a past event (because pictures). I tend to have to use the website. I uninstalled the Android app and now I just use the mobile website in a browser. I do have messenger installed cause that's what I actually use.
Personally.... I feel that if I don't use Onedrive I shouldn't see a prominent Onedrive icon always visible in Explorer or have onedrive.exe constantly running in the background using resources.
So I guess I'm stuck with using hacks to keep my operating system from shilling products at me.
I can't open files in VSCode that live in the WSL virtual file system. Which is a huge problem for setting up the same exact dev environment I have on my Mac.
It's honestly dumbfounding. VSCode works great on Mac with the existing terminal but the WSL team can't figure out a good way to allow you to edit WSL files from a normal Windows application.
That is not a solution. I want to work on files in my WSL home folder. Lots of language based package managers like npm and composer "live" inside a folder in your home directory. It's very important that VSCode running as a windows application be able to read/write to these files.
As it is right now I can't even edit my ~/.ssh/config from VSCode without jumping through hoops.
If you want to access your home folder in both, all you have to do is first create the folder in Windows, for example, create a wslhome folder inside your user folder in windows. Copy everything in your current WSL home folder, including hidden files, into that one. Then rename your WSL home folder to back it up and replace it with a symbolic link to the Windows folder. In WSL, use ln -s /mnt/c/Users/[your Windows user name]/wslhome /home/[your wsl user name]. The real folder exists in Windows and is usable in either environment.
> I want to work on files in my WSL home folder. Lots of language based package managers like npm and composer "live" inside a folder in your home directory. It's very important that VSCode running as a windows application be able to read/write to these files.
No. You don't want this. Linux and Windows are different platforms; if your Windows application could use your packages installed through Linux (and vice versa) then none of the native modules would work without a reinstall.
The side effects suck and they can make it better IMO but not sharing dependencies isn't an issue at all IMO.
> As it is right now I can't even edit my ~/.ssh/config from VSCode without jumping through hoops.
Yeah that sucks though for some things like git bash, etc, they use the proper windows home directory. So I end up just keeping those there and straight up copying or aliasing them to the WSL home folder.
Globally installed npm and composer packages live in ~/.npm/ and ~/.composer/ and they both have a global packages.json esque file that I need to occasionally edit. The packages installed in those folders MUST be parsed by VSCode for intelesense to work properly.
All I'm saying is I'm not gonna jump through all these hoops. I'd rather just keep working on my mac.
Hell I'd rather hackintosh a surface pro rather than deal with these issues.
npm/node works fine in Windows (and I'm pretty sure it's the same with composer), so why do you want to use it in WSL?
Edit: this is a genuine question of an engineer, who uses Git/npm/node for fullstack development on Windows 10 every day. What kind of setup do you have and what UX do you expect, that requires running the tools in WSL?
I just don't want to use Windows to test my code when production is in Linux. There are things all those tools do when running in Windows that is specific to Windows. And I'm not some anti-windows Microsoft hating guy. My main desktop is running Windows 10 and I was quite excited for WSL to come out so I had Windows 10 Insider Preview running on my machine for more than a year. But at the end of the day when I want to do "real" work I keep going back to my Macbook.
Windows command prompt compared to bash is simply horrible. I personally find Powershell to be just as bad. The console app in windows is still light years behind Terminal in OS X. In fact VSCode's built in terminal wrapper is orders of magnitude better.
Things like wkhtmltopdf to generate PDFs or ffmpeg to work with videos should run as they do in Linux on the production server. In OS X I can use brew to set things up. In windows I have to hunt down binaries, put them in the right place, and set the path manually via an OS level GUI many clicks down in Advanced Settings.
The extra work I need to do to make all those tools work in windows makes setting up a windows dev environment cumbersome and annoying. The way it's laid out in OS X gives me way cleaner interoperability with the way the code actually runs in a Linux environment.
It's one of the reasons I love WSL! Finally I can have a ~/.ssh/config in Windows! But I still can't edit the file from a Windows text editor.
Finally if I'm on a team where the production environment relies on some of these linux binaries being available I don't want to waste work hours researching and writing on boarding documentation for the one dev that feels like working in windows when the rest of us are on macs.
Stuff in lxss is treated "special" - files in that directory have unix numeric permissions on NTFS instead of ACL permissions. Windows doesn't know how to set those, so if win32 subsystem is updating permissions (for instance, on file save) and the linux subsystem is updating metadata (for instance, on file save), it's possible to end up in a state where neither subsystem is able to get permission to touch the file again.
For this reason, it is recommended to only edit files outside this directory from both subsystems (not to say this isn't issue-free, but it's relatively reliable.)
The file becomes invisible to WSL right after it gets edited in Windows. It's because it's doing weird tricks to associate UNIX permissions to files stored in Windows. The Windows app will break those permissions so instead of mitigating that in WSL it simply stops being able to "see" the file.
There's a perf hit. You may have noticed disk access in WSL outside this directory is slow. Inside this directory, wsl should be the same speed as w32 native, because it doesn't hit the magic layer.
