If people encouraged you to use native modules, then that was unfortunate.
I’m not sure I understand the issue with custom elements. Sure, they’re a bit complicated and half baked but it certainly doesn’t require a research lab to use them (in fact, I’ve just implemented one now).
I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.
I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.
Might it instead be the other way around: that customization-seeking companies are more likely to choose Mercurial? This could be either because adventurousness promotes both non-Git and customization, or because Mercurial has the better architecture when you need to customize. IIRC the latter is true for both Mozilla and Facebook. Anyway, at my second job we used vanilla Mercurial, and we did fine. It was basically the same as any Git workflow, for that matter.
Huh, well it’s very probable I’m just not aware of all the wild things people do out there with Mercurial. I frankly had no idea there were sub-repo extensions (outside of the core subrepo feature), and I don’t know why anybody would do custom authentication when SSH works everywhere (although I understand people might want to setup ActiveDirectory for Windows-only environments instead, but that’s it). What do you mean by “configuration extensions”? As for MQ, I don’t think it matters for the central repo, no? It should only matter for local workflows?
I suspect my issue might be more in my head (and my unique experience) than in reality. I have contracted with lots of git shops – and a fair number of mercurial ones. Most of the git shops worked very similarly, they differed in master dev versus feature branch dev, mono-repo or multi-repo – but they all felt similar and I could use very minor changes to my workflow to integrate with them, which is great for contracting.
Each mercurial shop has been a wild adventure in unique workflow, and brand new extensions I have never seen or used. One used TWO different sub-repo extensions, another one used THREE configuration extensions! On top of that, most of them had annoying/wonky authentication mechanisms (some hand-rolled). The reason I use those examples (which is only a fraction of what I have seen) is that are all basically non-optional. I needed to use them to be able to work on the project… and of course mq versus non-mq. Never used evolve (yet).
During the “will mercurial or git win?” – I was firmly on the mercurial side because I did work on Windows and git early on was non-function on it. But now when I hear a client is a mercurial shop, I dread it. But, I realize that is probably just my unique experience.
I would assume he’s talking about the kind of abuse you see often on Twitter (anything from randos to sockpuppets to bots to whatever). The original idea was that we’re limited to whatever moderation (or lack thereof) the Twitter HQ decides to do on their network, and on the other hand, various admins of Fediverse instances can do various amounts of moderation, so finding a “good” instance would in theory protect you better from harassment than Twitter. But the reality is that blocking/muting people might be harder on the Fediverse, where it’s harder to track the people behind the accounts, and given that instance admins have little credentials to show for, you could potentially get your data (PMs, etc.) stolen more easily than on Twitter.
Thing is, FUSE is slower, buggy (I’ve had kernel panics) and less flexible. A native way to track file system operations in a lossless manner would be really nice to have on linux.
I did this at the beginning but quickly switched over to ZNC because of bugs like that, the inability to have per-client history rollback, and other little details… I still use Weechat half the time on the client side though :) (I also use Textual on macOS, and Palaver on iOS).
I’ve been keeping an eye on IRCCloud – I currently keep a ZNC server running… playing with it has been quite fun and instructive so far, but I would be OK paying 5$/month for someone taking care of it all. I’m waiting for them to open up a bouncer service so we can connect with other clients than their official IRCCloud client… apparently it’s on their roadmap (see bottom).
Yes indeed. For those unfamiliar, here are (from the link) examples of the two docstring styles that Napoleon (a Sphinx extension) parses and renders. PyCharm, too, parses Numpy and Google docstrings and uses the information for tooltips, static analysis, etc.
Google style:
"""Summary line.
Extended description of function.
Args:
arg1 (int): Description of arg1
arg2 (str): Description of arg2
Returns:
bool: Description of return value
"""
return True
NumPy style:
"""Summary line.
Extended description of function.
Parameters
----------
arg1 : int
Description of arg1
arg2 : str
Description of arg2
Returns
-------
bool
Description of return value
"""
return True
No reason has been given.
Was locked automatically by some rules. Unlocked manually by Twitter support team. Could not use my phone number to unlock it right away. Says it’s “not supported”.
I didn’t do anything unusual. Have no idea how to prevent future locking.
But the point isn’t to even say that everything written here is true. The point is to share a very interesting data point that likely constitutes primary source material, and force a reaction from Tesla to stop their dangerous practices (or offer them a chance to set the record straight if any of this is untrue, which we’ve established is unlikely).
Most stuff your mentioning can be done without electronics or minimal use of them. They’re simple enough that they might also be able to use hardened electronics. There’s just nobody building cars that way due to no demand for RF-proof cars. We might see it happen in armored car side, though, if attackers start trapping important people in their cars.
“Every Tesla has GPS tracking that can be remotely accessed by the owner, as well as by Tesla itself. That means that people will always know where a Tesla is. This feature can be turned off, by entering the car and turning off the remote access feature. I am not sure why you would want to do this, but you can. Unfortunately, there are ways for a thief to turn off the remote access feature, and this will blind you to the specific information about the car. It will not stop Tesla from being able to track the car. They will retain that type of access no matter what, and have the authority to use it in the instances of vehicle theft.”
re taking trolls seriously. We’re calling you out about posting more unsubstantiated claims via Twitter. If your goal is getting info out, then you will always achieve it by including links like you gave me in the first place. Most people aren’t going to endlessly dig to verify stuff people say on Twitter. They shouldn’t since the BS ratio is through the roof. Also, that guy didn’t just make obvious claims like they could probably track/access the vehicle: he made many about their infrastructure and management that weren’t as obvious or verifiable. He also made them on a forum celebrated for trolling. So, yeah, links are even more helpful here.
Let’s go back to those old slant-6s or straight 8s - 12mpg, spewing leaded gas fumes, heavy, none of that fancy electronic safety stuff like airbags, real distributors with points that could wear down, etc. Sadly, all engineering involves tradeoffs - if we are lucky
If people encouraged you to use native modules, then that was unfortunate.
I’m not sure I understand the issue with custom elements. Sure, they’re a bit complicated and half baked but it certainly doesn’t require a research lab to use them (in fact, I’ve just implemented one now).
I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.
I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.
“Dangerous” compared to what? Force how?
Low-effort regurgitation of screencaps is not some big act of rebellion, it is just a way of lowering quality and adding noise.
If we wanted to read fiction we could go enjoy the sister Lobster site devoted to that activity.
Might it instead be the other way around: that customization-seeking companies are more likely to choose Mercurial? This could be either because adventurousness promotes both non-Git and customization, or because Mercurial has the better architecture when you need to customize. IIRC the latter is true for both Mozilla and Facebook. Anyway, at my second job we used vanilla Mercurial, and we did fine. It was basically the same as any Git workflow, for that matter.
Huh, well it’s very probable I’m just not aware of all the wild things people do out there with Mercurial. I frankly had no idea there were sub-repo extensions (outside of the core subrepo feature), and I don’t know why anybody would do custom authentication when SSH works everywhere (although I understand people might want to setup ActiveDirectory for Windows-only environments instead, but that’s it). What do you mean by “configuration extensions”? As for MQ, I don’t think it matters for the central repo, no? It should only matter for local workflows?
I suspect my issue might be more in my head (and my unique experience) than in reality. I have contracted with lots of git shops – and a fair number of mercurial ones. Most of the git shops worked very similarly, they differed in master dev versus feature branch dev, mono-repo or multi-repo – but they all felt similar and I could use very minor changes to my workflow to integrate with them, which is great for contracting.
Each mercurial shop has been a wild adventure in unique workflow, and brand new extensions I have never seen or used. One used TWO different sub-repo extensions, another one used THREE configuration extensions! On top of that, most of them had annoying/wonky authentication mechanisms (some hand-rolled). The reason I use those examples (which is only a fraction of what I have seen) is that are all basically non-optional. I needed to use them to be able to work on the project… and of course mq versus non-mq. Never used evolve (yet).
During the “will mercurial or git win?” – I was firmly on the mercurial side because I did work on Windows and git early on was non-function on it. But now when I hear a client is a mercurial shop, I dread it. But, I realize that is probably just my unique experience.
I would assume he’s talking about the kind of abuse you see often on Twitter (anything from randos to sockpuppets to bots to whatever). The original idea was that we’re limited to whatever moderation (or lack thereof) the Twitter HQ decides to do on their network, and on the other hand, various admins of Fediverse instances can do various amounts of moderation, so finding a “good” instance would in theory protect you better from harassment than Twitter. But the reality is that blocking/muting people might be harder on the Fediverse, where it’s harder to track the people behind the accounts, and given that instance admins have little credentials to show for, you could potentially get your data (PMs, etc.) stolen more easily than on Twitter.
Thing is, FUSE is slower, buggy (I’ve had kernel panics) and less flexible. A native way to track file system operations in a lossless manner would be really nice to have on linux.
My bad! :-)
https://medium.com/@farsi_mehdi/procs-and-lambdas-46433b93080d
I did this at the beginning but quickly switched over to ZNC because of bugs like that, the inability to have per-client history rollback, and other little details… I still use Weechat half the time on the client side though :) (I also use Textual on macOS, and Palaver on iOS).
I’ve been keeping an eye on IRCCloud – I currently keep a ZNC server running… playing with it has been quite fun and instructive so far, but I would be OK paying 5$/month for someone taking care of it all. I’m waiting for them to open up a bouncer service so we can connect with other clients than their official IRCCloud client… apparently it’s on their roadmap (see bottom).
Please use the
releaasetag for this, since the linked article has no information about unit, practices or webshit.Also, this is advertising and a newsletter signup even if it is for content that’s cool.
Which article?
Yes indeed. For those unfamiliar, here are (from the link) examples of the two docstring styles that Napoleon (a Sphinx extension) parses and renders. PyCharm, too, parses Numpy and Google docstrings and uses the information for tooltips, static analysis, etc.
Google style:
NumPy style:
Thanks for subscribing! :)
No reason has been given. Was locked automatically by some rules. Unlocked manually by Twitter support team. Could not use my phone number to unlock it right away. Says it’s “not supported”.
I didn’t do anything unusual. Have no idea how to prevent future locking.
But the point isn’t to even say that everything written here is true. The point is to share a very interesting data point that likely constitutes primary source material, and force a reaction from Tesla to stop their dangerous practices (or offer them a chance to set the record straight if any of this is untrue, which we’ve established is unlikely).
why aren’t you looking to optimize your queries?
Most stuff your mentioning can be done without electronics or minimal use of them. They’re simple enough that they might also be able to use hardened electronics. There’s just nobody building cars that way due to no demand for RF-proof cars. We might see it happen in armored car side, though, if attackers start trapping important people in their cars.
Thanks for the link. Key point:
“Every Tesla has GPS tracking that can be remotely accessed by the owner, as well as by Tesla itself. That means that people will always know where a Tesla is. This feature can be turned off, by entering the car and turning off the remote access feature. I am not sure why you would want to do this, but you can. Unfortunately, there are ways for a thief to turn off the remote access feature, and this will blind you to the specific information about the car. It will not stop Tesla from being able to track the car. They will retain that type of access no matter what, and have the authority to use it in the instances of vehicle theft.”
re taking trolls seriously. We’re calling you out about posting more unsubstantiated claims via Twitter. If your goal is getting info out, then you will always achieve it by including links like you gave me in the first place. Most people aren’t going to endlessly dig to verify stuff people say on Twitter. They shouldn’t since the BS ratio is through the roof. Also, that guy didn’t just make obvious claims like they could probably track/access the vehicle: he made many about their infrastructure and management that weren’t as obvious or verifiable. He also made them on a forum celebrated for trolling. So, yeah, links are even more helpful here.
Let’s go back to those old slant-6s or straight 8s - 12mpg, spewing leaded gas fumes, heavy, none of that fancy electronic safety stuff like airbags, real distributors with points that could wear down, etc. Sadly, all engineering involves tradeoffs - if we are lucky